Migrate from Symplify Communication to Salesforce Sales Cloud

Symplify Contacts map directly to Salesforce Contact. The unique originalId becomes a custom field symplify_original_id__c used as the dedupe key during import and for resolving DataDoc lookups. Standard fields (firstname, lastname, email, phone) map by field name. If the Symplify contact lacks an email address, we flag it for review before import because Salesforce requires email for Contact records without notable exceptions. All Contacts import before DataDocs to satisfy the parent lookup.

Each Symplify Document Type becomes a Salesforce Custom Object (__c suffix). We audit the Document Type definition during discovery, including any JSON Schema, to create the matching Salesforce field structure (text, number, picklist, date, checkbox types mapped appropriately). The originalId field on the DataDoc becomes a lookup relationship to the parent Contact symplify_original_id__c. Orphaned DataDocs without valid parent contacts go to a reconciliation queue for the customer to resolve before migration continues.

Symplify Lists are static contact groupings. We map each list to a Salesforce Campaign with Campaign Type set to Static List. List membership becomes CampaignMember records linking the Contact to the Campaign. If the customer uses dynamic segments in Symplify, we document the segment criteria for the admin to rebuild as Salesforce Report Filters or a Campaign inclusion rule rather than a live-synced segment.

Symplify Campaigns map to Salesforce Campaign. Campaign Name, StartDate, EndDate, and Channel (email, SMS, push) migrate directly. If the customer used project-level organization in Symplify, we either map to a Salesforce Campaign Folder hierarchy or flatten the structure into a naming convention (Project Name - Campaign Name) depending on the customer's preference documented during scoping.

Symplify Messages are individual sendout pieces within a Campaign. In Salesforce, the Campaign is the aggregation point; we store message-level metadata (subject line, send timestamp, send volume) in custom fields on the Salesforce Campaign or in a custom Message_Log__c object if the customer requires per-message granularity. If Salesforce Marketing Cloud is also in scope, we map to Campaign and EmailCampaign objects respectively.

Symplify open events track when a contact opened a message. We map opens to Salesforce Task records linked to the Contact and Campaign with TaskSubtype = Email and a custom field open_count__c incremented per unique open per message. Open timestamps preserve as ActivityDate. Multiple opens from the same contact on the same message aggregate into a single Task record with the open count as a field rather than creating duplicate Task rows.

Symplify sent records track every dispatch per contact per message. We map to Salesforce CampaignMember with Status = Sent and the send timestamp preserved in a custom field sent_date__c. Delivery status (delivered, bounced) maps to CampaignMember Status values. Sent volume per campaign is reconciled against the Salesforce Campaign MemberCount metric.

Symplify click events track URL-level engagement within messages. We map clicks to Salesforce Task records linked to the Contact and Campaign with a custom field click_url__c (the clicked URL) and click_count__c. Click timestamps preserve as ActivityDate. Unique click URLs per message aggregate similarly to open records to avoid Task proliferation.

Symplify hard bounce records mark permanently undeliverable contacts. We set Contact.HasOptedOutOfEmail = true and populate a custom field symplify_bounce_type__c = 'Hard' and symplify_bounce_date__c = the original bounce timestamp. This preserves the bounce state for deliverability audit and ensures no further emails send to that address from Salesforce or any integrated email tool.

Symplify soft bounce records indicate temporary delivery failures. We set a custom field symplify_bounce_type__c = 'Soft' and symplify_bounce_date__c = the original timestamp. Salesforce does not suppress sends on soft bounces by default, so we document the soft bounce threshold policy (typically three soft bounces trigger suppression) for the customer's admin to implement as a Salesforce Flow or marketing automation rule.

Symplify optout records track unsubscribe preferences. We set Contact.HasOptedOutOfEmail = true and populate a custom field symplify_unsubscribed_date__c with the original optout timestamp. This satisfies GDPR and CAN-SPAM compliance requirements at the destination. If the customer also uses Salesforce Marketing Cloud Account Engagement, we sync HasOptedOutOfEmail to the Prospect record via the native integration.

Symplify Projects are organizational containers for Campaigns and workflows. Salesforce does not have a Project object in Sales Cloud; we map Projects to Salesforce Campaign Folders (folders containing related Campaigns) or apply a naming convention that embeds the project name in each Campaign record. If the customer uses Project-level reporting, we document the recommended folder hierarchy for the admin to implement post-migration.

Symplify does not expose a user management object in the same way Salesforce does. We resolve Symplify owners by matching the contact's last_modified_by or assigned_owner_id (if exposed via API) to a Salesforce User by email. Owners without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision. The migration cannot insert records with OwnerId references that do not resolve to valid Salesforce Users.