Migrate from Insider to Salesforce Sales Cloud

Insider Users with lifecycle stage values of active customer, subscriber, or registered user map to Salesforce Contact tied to an Account. Users without a purchase or engagement history map to Salesforce Lead. We extract the full user profile including email, phone, name, device identifiers, and all custom attributes, then apply a split rule during scoping based on the customer's Insider lifecycle stage matrix. The original Insider lifecycle stage value is preserved in a custom field insider_lifecycle_stage__c on both Lead and Contact for audit and reporting continuity.

Insider event streams (page views, add-to-cart, purchase, custom events) export with event_name, timestamp, and all event_parameters. For behavioral analytics use cases, we create a custom Activity__c object in Salesforce with fields for event_type__c, event_name__c, event_timestamp__c, and a JSON parameter blob. For operational use cases (e.g., last-purchase-date driving a workflow), we extract key events as flattened custom fields on Contact. The customer chooses the event strategy during scoping based on whether they use Salesforce reporting or a separate analytics tool post-migration.

Insider Segments are defined by attribute rules and event conditions. We export the member list (user IDs) and the segment rule definition as metadata. Member lists migrate as Salesforce Campaign Members attached to a Campaign record representing the segment. The rule definition is documented in the handoff inventory; segment rule logic does not mechanically translate to Salesforce because Salesforce Campaigns do not support event-triggered dynamic membership. If the customer uses Salesforce Marketing Cloud Account Engagement (Pardot), segments map to Pardot Static Lists or Dynamic Lists.

Insider product catalog data including sku, name, price, category, images, and custom attributes maps directly to Salesforce Product2 records. We preserve the product hierarchy (parent category, subcategory) as custom fields on Product2 and create Standard Pricebook entries during import. Any custom product attributes stored as key-value pairs in Insider become custom fields on Product2 with appropriate Salesforce field types.

Insider transaction objects capture order_id, total, currency, items, and timestamps. For Salesforce Sales Cloud destinations, we map transactions to Opportunity with Line Items, creating the Opportunity at the time of the first transaction and appending subsequent transactions as additional OpportunityLineItems. For Salesforce Commerce or Order Management destinations, transactions map directly to the Order object. The customer confirms the order model during scoping.

Insider Users can have arbitrary custom properties beyond the standard profile schema. We export all custom attributes as flat key-value columns and map them to Salesforce custom fields on Contact or Lead (depending on the split decision). Field types are determined by value inspection: numeric values become Number fields, date values become Date fields, boolean flags become Checkbox fields, and free-text values become Text fields. Picklist values with a defined set become Picklist fields with the values whitelisted. We pre-create all custom fields in the destination Salesforce org via metadata API before data load begins.

Insider Lists are static user collections beyond segment-based dynamic membership. We export list membership (user ID + list ID) and recreate list membership in Salesforce as Campaign Members attached to a Campaign record representing the list. List names and descriptions are preserved in the Campaign Name and Description fields. If the customer uses Salesforce Groups for internal segmentation, we recreate list membership as Group Members.

Insider tags export as an array of string labels per user. We preserve the full tag array and recreate it in Salesforce as a multi-select picklist field on Contact or Lead. If the customer uses Salesforce Topics for content classification, tags migrate to Topic records with TopicAssignment links. The customer chooses the tag strategy during scoping based on their reporting and workflow needs.

Insider channel configuration including sender IDs, phone numbers, WhatsApp business account credentials, email template assets, and opt-in/opt-out settings does not export mechanically. We document the current channel configuration during discovery so that the customer can re-register sender IDs, WhatsApp business numbers, and email sending domains in Salesforce or the customer's chosen sending infrastructure (Salesforce Marketing Cloud, SendGrid, Twilio). Channel templates do not migrate; we recommend rebuilding email and SMS templates using Salesforce Content Builder or the customer's preferred template editor.

Insider Journeys are multi-step event-driven workflows with entry triggers, conditional gates, channel steps, and exit conditions. Insider provides no API endpoint to export Journey definitions, automation rules, or trigger logic. We export Journey definitions as a written audit deliverable documenting every active Journey including its trigger conditions, step sequence, conditional branches, channel actions, and exit criteria. The customer's Salesforce admin uses this documentation to rebuild equivalent logic in Salesforce Flow or Flow Builder. Journey rebuild is out of migration scope and is a separate engagement.

Insider users referenced as owners on profiles, segments, and journeys map to Salesforce User records. We resolve owners by email match against the destination Salesforce org's User table. Any Insider owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

If the customer has email engagement history stored in Insider (sent emails, open events, click events), we map these to Salesforce EmailMessage records (the email content) linked to an Activity Task record (the activity timeline entry). The WhoId on Task points to the Contact or Lead; WhatId points to the related Opportunity or Account. Email engagement events (opens, clicks) are stored as custom fields on the EmailMessage or as a separate EmailEngagement__c custom object.