Migrate from Interactive to Salesforce Sales Cloud

Interactive pipeline stages require Salesforce Record Type provisioning before data loads

Interactive's single-pipeline model means all deal stages live in one namespace. Salesforce scopes Opportunity StageName pick-list values to the active Sales Process, which is itself keyed by the Opportunity's RecordTypeId. If Interactive has four pipelines with overlapping stage names — for example, 'Proposal' appears in both a New Business pipeline and an Upsell pipeline — those stages must be separated into distinct Record Types with their own stage pick-lists before Opportunity records can load. Loading Opportunities against a non-existent Record Type causes validation failures. We deliver a Record Type and Sales Process setup plan as the first deliverable so Salesforce admins can pre-create the schema.

N:N contact-to-company associations collapse to a single AccountId plus Account Contact Relations

Interactive supports multiple company associations per contact — a sales rep might associate a contact with both their employer and a partner organization. Salesforce Contact accepts only one AccountId as the primary lookup; additional company links must be stored in the Account Contact Relation object, which has its own Role and IsDirect fields. We migrate one primary company (the most recently modified, or by a rule you specify) as the AccountId and surface the remainder as Account Contact Relations. If your reporting relies on the full N:N graph, rebuilding the relationship view in Salesforce requires a custom report type or a junction-object query.

Custom fields must be pre-created in Salesforce before the migration run commits any data

Interactive stores custom properties in the same object as standard fields, but Salesforce requires every custom field to be defined in Setup (or via Metadata API) before a record containing that field can be saved. The __c suffix fields cannot be populated on the first load if they do not yet exist in the org. We generate a custom-field manifest listing every Interactive custom property, its Salesforce data type, and pick-list values if applicable, so your admin creates them before the migration runs. A common failure mode is a Salesforce validation rule referencing a field that has not been created yet — we check validation rule dependencies against the manifest before loading.

Interactive activity timestamps on Tasks and Events require post-load audit because Salesforce sets its own date stamps

Salesforce Tasks and Events carry system timestamps — CreatedDate, LastModifiedDate, and ActivityDate — that reflect the migration run, not the original Interactive activity date. The original timestamps are critical for reports such as 'average time to first call' or 'days since last contact'. We preserve the original Interactive timestamp in custom datetime fields (Original_Activity_Date__c for Tasks, Original_Start_DateTime__c for Events) so reporting continuity is maintained. However, Salesforce's native 'Last Activity Date' field on Contact and Opportunity is calculated from the system-level ActivityDate and cannot be overridden, so that field will show the migration date until new activities are logged.

Owner resolution by email match can silently demote records to the wrong user if Salesforce User emails have changed

FlitStack resolves Interactive owner_id to Salesforce OwnerId by matching the owner's email address against Salesforce User records. This works correctly in most cases. However, if a Salesforce User has changed their email address since the account was provisioned, the email match fails silently and the record is assigned to the fallback owner — typically a system admin. We flag every unmatched owner before committing the migration and present a resolution list so your team can either correct the Salesforce User email or pre-provision the missing user accounts. Active deals assigned to the wrong owner after migration can disrupt pipeline reporting.