Migrate from Zymplify to Salesforce Sales Cloud

Zymplify Contact records with lifecycle stage values indicating an unqualified prospect (subscriber, marketing qualified) map to Salesforce Lead. Contacts with sales-qualified or customer lifecycle stages map to Salesforce Contact tied to an Account. We compute the split at migration time using Zymplify's lifecycle stage property and preserve the original stage in a custom field zymplify_lifecycle__c on both Lead and Contact for audit. The CDP Hub's contact records carry enrichment provenance that we surface as a custom field zymplify_enrichment_source__c.

Zymplify Company records map directly to Salesforce Account. The Company domain maps to Account Website and serves as the dedupe key during import. Each Company carries intent signal metadata (Bombora-powered intent spikes, G2 Buyer Intent signals) that we extract and write as custom fields on the Account: zymplify_bombora_intent__c, zymplify_g2_intent__c, and zymplify_signal_source__c. Account is created before any Contact import so that the AccountId lookup is satisfied at Contact insert.

Zymplify Deals map to Salesforce Opportunity. Pipeline stages map to Salesforce StageName via a configurable mapping table. We flag that Zymplify Deals commonly lack a required Close Date or Amount — a structural difference from Salesforce's mandatory Opportunity fields. During scoping, we identify Deals without Close Date and either apply a default migration-date close date or surface them as a data-quality issue for customer remediation before import.

Zymplify pipeline stages map to Salesforce Opportunity Stage values. We create a Salesforce Record Type and corresponding Sales Process that whitelists the relevant stage values before migration begins. Stage probability percentages from Zymplify migrate to Salesforce StageProbability rounded to the nearest integer.

Zymplify Sales Cadences are outreach sequences combining email steps, delays, and task actions. They have no direct Salesforce equivalent in Sales Cloud. We export the cadence structure (steps, delays, action types, trigger conditions) as a sequence definition document and recommend the customer rebuild using Salesforce Sales Engagement (High Velocity Sales) or a standalone Sales Engagement platform. The cadence step content (email templates, tasks) migrates as Salesforce EmailTemplate records and Task templates for manual admin use.

Zymplify Marketing Workflows are automation builders with triggers, conditions, and actions that do not transfer to Salesforce Flow as code. We document every active Zymplify workflow (trigger, conditions, actions, sequence) as a requirements specification that the customer's Salesforce admin or a Salesforce partner uses to rebuild equivalent Flow automations. Workflow documentation is delivered as part of the migration handoff package.

Zymplify customer health scores and churn risk indicators are native calculations with no Salesforce equivalent. We export the raw health metrics (risk signals, health score components) as custom fields on Account: zymplify_health_score__c, zymplify_churn_risk__c, and zymplify_risk_factors__c. The scoring model itself is not portable; we document it for the customer to rebuild in Salesforce using Flow formulas or a health-score app from the AppExchange.

List management and deduplication records from Zymplify's CDP Hub carry enrichment status and source attribution. We import the cleansed contact data as Salesforce Contact records and add a custom field zymplify_cdp_status__c that records the enrichment and deduplication decision. Source-of-record attribution migrates to a custom field so downstream enrichment tools can distinguish Zymplify-enriched records from records enriched post-migration.

Zymplify products map to Salesforce Product2 records with Standard Price Book entries created during import. ProductCode maps from Zymplify's SKU field. If Zymplify products are associated with Deals, we also migrate Line Items after resolving the Pricebook2 reference.

Zymplify email engagements migrate to Salesforce EmailMessage records (email content) linked to an Activity Task record (timeline entry). The WhoId on Task points to the migrated Lead or Contact; WhatId points to the related Opportunity or Account. Activity ordering is preserved by setting ActivityDate to the original Zymplify timestamp.

Zymplify call engagements map to Salesforce Task with TaskSubtype = Call. Call duration and disposition from Zymplify transfer to custom Task fields. The Activity timeline ordering is preserved using the original Zymplify timestamp as ActivityDate.

Zymplify meeting engagements map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Attendee mapping creates EventRelation records pointing at the migrated Leads, Contacts, and Salesforce Users. Location and meeting notes from Zymplify migrate to the Event Description field.

Zymplify Notes (engagement type NOTE) migrate to Salesforce Note records linked via ContentDocumentLink to the parent record (Lead, Contact, Account, Opportunity). Rich text and attachment references in Zymplify Notes migrate as Salesforce Note body text; actual file attachments migrate as ContentDocument records with ContentDocumentLink to the parent.

Zymplify Task engagements map to Salesforce Task with Status, Priority, and ActivityDate preserved. Task assignment migrates by resolving Zymplify hub_id to Salesforce UserId via the User mapping.

Zymplify custom fields are supported across all object types but the export schema is not publicly documented. We discover the custom field inventory during the discovery phase — querying Zymplify's API to enumerate field names, types, and object assignments — and map each field to a typed Salesforce custom field. Field types are resolved at discovery: text to Text(255) or TextArea, numeric to Number, date to Date, picklist to Picklist. Custom field naming follows Salesforce __c convention with a zymplify_ prefix to distinguish migrated fields.

Zymplify User records include role, hub assignment, and ownership relationships. We map active users to Salesforce User by email match. Any Zymplify User without a matching Salesforce User goes to a reconciliation queue for admin provisioning before record import. Role-based access information from Zymplify is preserved as a custom field zymplify_role__c on the mapped Salesforce User record.

Tags applied to Zymplify Contacts and Companies are Zymplify-native. We export tags as a custom text field zymplify_tags__c (comma-separated) on the relevant Salesforce object. If the customer prefers Salesforce's native tagging taxonomy, we deliver a tag vocabulary document for the admin to rebuild using Salesforce Topics or a custom multi-select picklist.