Migrate from Symplify Communication to Freshsales

Symplify Contacts map to Freshsales Lead (for unprocessed or marketing-qualified prospects) or Contact (for qualified buyers attached to an Account). We apply a split rule during scoping: Contacts with no associated DataDoc purchase history or deal association become Leads; Contacts with purchase events or behavioral data stored in DataDocs become Contacts linked to a Freshsales Account. The originalId from Symplify is preserved in a custom field symplify_original_id__c on both Lead and Contact for cross-reference.

DataDocs store relational records (purchase history, event attendance, booking data) linked to Symplify Contacts by originalId. Each Document Type defines mandatory fields including originalId and externalId plus any JSON Schema. We pre-create Freshsales custom objects matching each Document Type schema before migration begins. If a Document Type definition is missing or orphaned DataDocs exist without a valid type, we flag these during discovery and exclude them from migration until the customer resolves the type structure. JSON data within DataDocs is stored as a long-text custom field in JSON format for programmatic access.

Symplify Lists are static contact groupings. We export list membership and recreate list names as Freshsales Static Lists. If the customer uses lists for segmentation logic (e.g., VIP, churned, new subscriber), we encode these as custom multi-select picklist values on the Lead or Contact (e.g., list_membership__c) rather than recreating separate list objects, since Freshsales does not have a native standalone list object equivalent to Symplify Lists.

Symplify Campaigns store send metadata (name, send date, channel, status). Freshsales does not have a native Campaign object in the base CRM; that exists in Freshmarketer. For each Symplify Campaign, we create a Note on the associated Contact records with campaign name, send date, and channel. If the customer moves to Freshsales Suite, we map campaigns to Freshmarketer Campaign records via the cross-product integration.

Symplify tracks open events per message per contact with timestamps. Freshsales has no native email marketing open tracking object. We aggregate open counts per contact and store them in a custom field email_open_count__c (integer) and a related custom object email_campaign_activity__c linking contact to campaign name and last open date. Per-message open detail is not recoverable in Freshsales without Freshmarketer.

Symplify tracks click events per URL per message per contact. We aggregate click URLs and total click count per contact into a custom field email_click_count__c and a related email_campaign_activity__c record. The original clicked URL and timestamp are stored as JSON in a long-text field for audit purposes.

Symplify Hard Bounce records mark permanently undeliverable contacts. We export all hard bounce events by contact and set HasOptedOutOfEmail = true in Freshsales for deliverability compliance. We also store the bounce date and bounce reason in custom fields bounce_date__c and bounce_reason__c on the contact record.

Soft Bounce records indicate temporary delivery failures. We export soft bounce events with timestamps and bounce codes and store them in a custom field soft_bounce_history__c (long-text JSON array) on the contact record. Soft bounces do not set HasOptedOutOfEmail in Freshsales, consistent with deliverability best practices, but the history is preserved for the customer's admin to review.

Symplify Optout records track unsubscribe preferences with timestamps. We export all optout events and set HasOptedOutOfEmail = true in Freshsales, preserving the optout timestamp in a custom field unsubscribed_at__c. This ensures CAN-SPAM and GDPR compliance in the destination system and prevents accidental re-sending.

Symplify Projects are organizational containers grouping campaigns and workflows. Freshsales does not have a native project-level container object. We map project structure to Freshsales Folders (for UI organization) or Tags (for cross-record classification) depending on the customer's intended use case. This is decided during scoping since projects often contain workflow logic that will not migrate.