Migrate from Zixflow to Salesforce Sales Cloud

Zixflow Contacts map directly to Salesforce Contact. Standard fields (name, email, phone, address) map to their Salesforce equivalents. Custom fields on Zixflow Contacts map to custom fields on Salesforce Contact (__c suffix) with type mapping: text to Text(255), number to Number, date to Date, dropdown to Picklist. We extract the custom field schema via the Zixflow API first, then provision matching Salesforce custom fields in a Sandbox before data migration begins. Any AI-generated custom fields from Zixflow carry a zf_ai_generated__c flag for transparency.

Zixflow Collections are list-grouping constructs that organize Contacts. Salesforce has no native grouping object, so we use a two-part strategy: the Collection itself becomes a Custom Object (Collection__c) with Name and Description, and membership maps to a junction object (CollectionMember__c) with lookup relationships to both Collection__c and Contact. This preserves Collection semantics without flattening the grouping. If the customer prefers a simpler model, Collections also map as tags on Contact records via a multi-select picklist.

Zixflow custom fields on Contacts (including AI-generated custom fields) map to Salesforce custom fields on Contact. We extract the full field definition schema via the Zixflow REST API before migration, then pre-create all Salesforce custom fields via the Metadata API. Field type mapping: Zixflow text to Salesforce Text(255), Zixflow number to Number, Zixflow date to Date, Zixflow dropdown to Picklist, Zixflow multi-select to Multi-Select Picklist. Validation rules and required-field constraints are documented separately for the Salesforce admin to configure post-migration.

Zixflow Flows define automation logic as a node-graph inside the visual builder. The workflow structure is not portable to Salesforce Flow, which uses a different action model (record-triggered, scheduled, screen variants) and different trigger semantics. We inspect each active Flow during scoping, document its trigger conditions, action sequence, and delay logic in a structured runbook with a recommended Salesforce Flow equivalent. The customer's admin rebuilds the automations post-migration using the runbook.

Zixflow Inbox threads contain multi-channel message history across WhatsApp, SMS, Email, and RCS. We flatten threads into time-ordered records: each inbound and outbound message becomes a Salesforce Task with TaskSubtype set to Email, Call, or Chat depending on channel. Message content migrates as Task Description. Attachments migrate as ContentDocumentLink records attached to the Task. Channel metadata (WhatsApp Business ID, SMS provider) is preserved in custom Task fields. We use the Salesforce Bulk API 2.0 for large thread volumes with chunking and exponential backoff.

Zixflow Form submissions capture lead data at point of entry. Each Form submission becomes a Salesforce Task linked to the Contact (or a Lead if the contact is new), with the Form name and submission timestamp as custom Task fields. Field values from the Form populate the corresponding Contact or custom object fields. We preserve the Form field structure as a custom object (FormSubmission__c) with field-level mappings for audit traceability.

Zixflow User accounts represent seats. We map Zixflow Users to Salesforce Users by email match. The customer's Salesforce admin provisions any missing Users in the destination org before record migration begins. Role and permission structures (Zixflow workspace roles) do not transfer directly; they must be recreated in Salesforce with the appropriate profile and permission set assignments.

Customers who used Zixflow during or after its Sales Simplify era may have deal records that were not portable at rebrand. We treat these as Opportunities with a legacy_source__c = 'Sales_Simplify' flag and map deal fields to Opportunity standard fields (Amount, CloseDate, StageName). If deal fields do not map cleanly to standard Opportunity fields, we create custom Opportunity fields (Deal_Value__c, Deal_Status__c) to preserve the original data. No Deals object exists in current Zixflow schema; deal-like records in a Sales Simplify export are processed as Opportunities during migration.

Analytics data (open rates, click rates, delivery metrics, campaign performance) in Zixflow are aggregated reporting outputs generated at query time. They are not stored as discrete records and cannot be exported as structured data. We do not migrate analytics. We recommend rebuilding key reports in Salesforce Reports & Dashboards post-migration using the migrated Contact, Account, and Opportunity data as the foundation.

WhatsApp, SMS, Email, and RCS messaging credits are consumed from a Zixflow wallet balance. This is a billing artifact with no data portability value. Wallet balances reset to zero upon account closure and are not migrated. Messaging cost history is an analytics artifact (see above) and does not transfer.

Flow automation credits control how many workflow actions execute per month under the Zixflow subscription. Credits are non-transferable usage tokens. We do not migrate this allocation. The customer's messaging and automation costs restart at the destination platform with its own billing model.

Zixflow's LinkedIn extension enriches Contact records with LinkedIn profile data. LinkedIn URL, company headline, and connection count migrate as custom fields on Salesforce Contact (LinkedIn_URL__c, LinkedIn_Headline__c). We do not migrate LinkedIn messaging history or InMail data as these are LinkedIn-platform records outside Zixflow's exportable scope.