Migrate from Spotler Mail+ to Salesforce Sales Cloud

Spotler Mail+ contacts map to Salesforce Lead by default since Spotler is a marketing-originated contact database without a native sales-qualified vs marketing-qualified distinction. We preserve the original Spotler contact ID in a custom field spotler_contact_id__c for audit traceability. Email opt-in and GDPR consent flags map to HasOptedOutOfEmail and a custom consent field. If the customer already has a Salesforce org with existing Leads, we run dedupe matching on email address before insert to avoid duplicate records.

For customers who already use Salesforce CRM alongside Spotler Mail+ and want contacts consolidated, we map Spotler contacts to Salesforce Contact directly. In this configuration, the Spotler contact becomes a Salesforce Contact linked to an Account. We resolve the Account by domain match (using the contact's email domain as a lookup key) or by a customer-provided Account mapping table. If the Spotler contact has no matching Account, we create a placeholder Account record with the domain as the Account Name.

Spotler audience segmentations are static or dynamic contact sets built from tag filters, score thresholds, selections, and exclusions. Each Spotler segmentation becomes a Salesforce Campaign, and the resulting contact memberships migrate as CampaignMember records with Status = Sent (for contacts who received at least one mailing) or a customer-defined status mapping. Dynamic segmentation rules do not transfer as executable logic; we extract the resulting contact sets as static lists and deliver a written rule inventory for the admin to rebuild as Salesforce Reports or Flow-based segmentation.

Spotler contact tags are flat label attributes stored per contact. We map them to a Salesforce custom text field with a semicolon-separated list of tag values (spotler_tags__c). If the customer has fewer than 500 distinct tag values, we optionally create a custom multi-select picklist field to preserve the tag vocabulary as structured picklist values. The choice between text and picklist is made during scoping based on Salesforce field governance.

Spotler lead scores are numeric values stored as contact properties. We map them directly to a Salesforce custom number field score__c on Lead or Contact. If Spotler stores multiple score dimensions (behavioral score, demographic score, or model-based scores), each dimension maps to a separate number field with its name suffixed to the field API name (e.g., behavioral_score__c, demographic_score__c). The customer confirms score model structure during scoping.

Spotler Mail+ supports text, numeric, currency, list, date of birth, date, and permission field types. We map each to its Salesforce equivalent: text to Text(255) or Long Text Area, numeric to Number, currency to Currency, list to Picklist or Multi-Select Picklist, dates to Date, and permission/boolean to Checkbox. Spotler database field names must match import column headers exactly; we validate field names against Spotler's field registry before transformation to catch any naming discrepancies that would silently drop data during import.

Mailing send history, open records, click records, bounce records, and unsubscribe records map to Salesforce Campaign and CampaignMember. Each Spotler mailing campaign becomes a Salesforce Campaign with Campaign Type = Email. Spotler contacts who were sent the mailing become CampaignMember records with Member Status mapped to Spotler's delivery outcome (Sent, Bounced, Unsubscribed). Open and click interaction counts store in custom number fields on CampaignMember. We scope this migration to the most recent 24-month window per Spotler's anonymization policy; records older than 24 months will return empty or scrubbed in Spotler export queries and cannot be recovered regardless of export method.

Spotler form submissions are stored as request objects linked to contacts, with each form field producing a data point. We denormalize form submissions into custom fields on the Salesforce Contact or Lead record (form_field_name__c), or into a related Task record if the form has multiple fields and a timeline-oriented structure is preferred. Survey questions and answers do not export as a relational structure; we flatten them to field-value pairs. Form closure rules (date-triggered or quota-triggered) do not export and must be recreated manually in Salesforce.

Spotler email template content, images, and styles export as HTML/CSS assets. We extract the rendered HTML from each template for reassembly as a Salesforce EmailTemplate or Marketing Cloud Content Builder HTML block. The drag-and-drop layout and component positioning do not port; we deliver a template content package (HTML, inline CSS, image URLs) and a written template reconstruction guide. If the customer licenses Marketing Cloud, we deliver HTML assets formatted for Content Builder import.

Spotler landing pages are platform-native assets with embedded forms and interactive elements. We export available page content and structure where the export API exposes them, but interactive components (embedded forms, dynamic content blocks, styling) require reassembly. We deliver a written asset inventory listing every Spotler landing page URL, form ID, and content summary for the customer's admin to rebuild as a Salesforce Experience Cloud page, Marketing Cloud Landing Page, or external CMS page.

Spotler user accounts with names, emails, and role assignments extract for mapping to Salesforce User records. We match Spotler users to Salesforce Users by email address. Any Spotler user without a matching Salesforce User is placed in a reconciliation queue; the customer's admin provisions the missing Salesforce Users (or deactivates the role assignment if the Spotler user is no longer active) before the final record import.

Spotler automated campaign logic including triggers, drip sequences, and behavioral actions is platform-native and cannot be exported as executable rules. We do not migrate workflows or automation logic. We deliver a written inventory of every active Spotler automation with its trigger conditions, action sequence, and estimated Salesforce Flow equivalent, plus a recommended rebuild sequence. The customer's admin or a Salesforce implementation partner rebuilds them post-migration. This object appears in the migration scope only as a documentation deliverable.