Migrate from Contlo to Salesforce Sales Cloud

Contlo Contacts with no purchase history or engagement stage below a defined threshold map to Salesforce Lead. Contacts with confirmed purchase events, subscription status, or engagement above the qualified-buyer threshold map to Salesforce Contact attached to a newly created or pre-existing Account. We compute the split rule during scoping based on the customer's segment definitions and lifecycle data, preserving the original Contlo contact_id in a custom field contlo_id__c on both Lead and Contact for audit and cross-reference.

Contlo Company records map to Salesforce Account. Where a Contlo Contact has no explicit Company association, we extract the domain from the Contact email address and create an Account record using domain-based grouping. Account.Name maps from Company name; Account.Website maps from Company domain. Account is created before Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

Contlo Segments are behavioral groupings (e.g., Abandoned Cart, VIP, Recent Purchaser). We create a Salesforce Campaign per Contlo Segment, preserving the segment name as Campaign Name and segment creation date as Campaign CreatedDate. Each Contlo Contact in that Segment becomes a CampaignMember record on the corresponding Salesforce Campaign, with Member Status mapped from Contlo's enrollment state (Active, Exited, Paused). Segment membership as tags on Contact also migrates as a multi-select picklist custom field for quick filtering without Campaign navigation.

Contlo email and SMS campaigns migrate to Salesforce Campaign records with Campaign Type set to Email or SMS. Campaign description, scheduled date, and send status migrate as standard Campaign fields. Template content migrates as Campaign Managed Content or as a custom rich-text field if the destination org does not have Content Management enabled. Delivery logs (send, bounce, delivery counts) are preserved as campaign statistics in Salesforce Campaign fields.

Contlo engagement events (email opens, clicks, SMS replies, conversions) migrate as CampaignMemberStatus transitions on the corresponding Salesforce CampaignMember record. Each engagement event type creates a timestamped entry, preserving the open and click timeline per contact per campaign. This preserves behavioral history without requiring a custom activity object.

Contlo custom fields on Contact records map to Salesforce custom fields on the Lead and Contact objects. We use the Salesforce Field Type Picker to match Contlo field types (text, number, date, boolean, dropdown) to the closest Salesforce equivalent. Multi-value properties map to Salesforce multi-select picklists. Fields that have no Salesforce equivalent are stored in a JSON blob custom field contlo_custom_data__c for retrieval if needed.

Contlo automations are extracted as structured JSON describing trigger type, conditions, time delays, and action steps. Because Salesforce Flow uses a different execution model (record-triggered vs. event-triggered branching), we do not migrate automations as code. We deliver a written automation inventory document listing every active Contlo automation with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. The customer's admin rebuilds each automation in Flow post-migration.

Contlo Voice Agent configuration (routing logic, voice settings, prompt templates) is extracted as structured data in the migration export. Voice Agent logic itself is a platform-native feature that cannot be recreated in Salesforce without a rebuild. We map Voice Agent settings to a custom Salesforce object Voice_Agent_Settings__c and document the routing and prompt structure so the customer's admin can recreate the agent using Salesforce Service Cloud Voice or a third-party voice integration (AWS Connect, Five9) post-migration.

Contlo's Brand AI Model is a proprietary platform artifact trained on the customer's campaign content and customer data within Contlo's infrastructure. It is not a portable data object and cannot be exported in any migration format. We mark this explicitly in the pre-migration discovery document as a manual action item: the customer must re-train or re-configure an equivalent model in Salesforce Einstein AI, Google Vertex AI, or another third-party AI service post-migration. We do not include Brand AI Model data in the migration scope and do not charge for it.

Contlo event-level data (opens, clicks, conversions, revenue attributed) is exported as a time-series dataset linked to Contact ID. We load this as rows in a custom Salesforce object Contlo_Engagement_History__c with fields for contact_id, campaign_id, event_type, event_timestamp, and event_value. This preserves the full behavioral timeline for reporting purposes even though it sits outside the standard Salesforce Activity timeline. The customer's admin can build Salesforce Reports against this custom object or connect it to Einstein Analytics.

Contlo Users (owners assigned to Contacts, Companies, and Campaigns) map to Salesforce User records by email address match. We extract every distinct owner referenced across the migration scope and match against the destination Salesforce org's User table. Any Contlo Owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes, because OwnerId references are required on most standard Salesforce objects.

Contlo's email subscription preference (subscribed, unsubscribed, cleaned) maps to Salesforce's HasOptedOutOfEmail boolean and to CampaignMember.Status for each campaign enrollment record. SMS and voice opt-in preferences migrate to custom boolean fields sms_opt_in__c and voice_opt_in__c on Contact, ensuring compliance flags are preserved across channels.