Migrate from Sanoflow to Salesforce Sales Cloud

Sanoflow Contacts map to Salesforce Lead if the contact represents an unqualified inbound enquiry or prospect, and to Salesforce Contact attached to an Account if the contact represents a qualified buyer or active customer. We determine the split by evaluating the Enquiry lifecycle: contacts with an associated open or recent Enquiry become Leads; contacts with a closed Enquiry or a Pipeline stage assignment indicating active opportunity become Contacts on an Account. The original Sanoflow contact record ID is preserved in a custom field sanoflow_contact_id__c on both Lead and Contact for audit and cross-reference.

Sanoflow's Company concept (if used alongside Contacts) maps to Salesforce Account. Where Sanoflow Contacts are stored without an explicit company, we derive the Account name from the contact's domain or company name Custom Field. The Account is created before any Contact import so that AccountId is satisfied at Contact insert time. If no company data exists, the contact becomes a Lead instead.

Sanoflow Enquiries represent inbound customer messages or form submissions and map differently depending on their business context. Support-type Enquiries (incoming questions, complaints, or service requests) map to Salesforce Case if Service Cloud is active in the destination org. Sales-type Enquiries (inbound interest, qualification requests) map to Task records attached to the corresponding Lead or Contact. We identify the split during scoping by examining the Flow routing rules and agent assignment patterns that determine how Enquiries are handled.

Each Sanoflow Pipeline becomes a Salesforce Record Type on Opportunity (or Case for service pipelines). The Record Type gets a corresponding Sales Process that whitelists the destination stage values matching the Sanoflow Pipeline Stage order. Stage probability percentages migrate from Sanoflow to Salesforce StageProbability fields, rounded to the nearest integer per Salesforce constraints.

Sanoflow Pipeline Stages map to Salesforce Opportunity StageName values. Stage names, order, and completion criteria are preserved 1:1 in the destination Sales Process. Stage-specific automation rules from Sanoflow (such as auto-assignment or notification triggers) are documented in the Workflow Specification Document rather than migrated as they have no equivalent in Salesforce Flow without manual rebuild.

Sanoflow Channels represent connected messaging platforms (WhatsApp, Instagram, Messenger, TikTok). Channel configurations cannot be migrated because WhatsApp Business API credentials and Meta Business account associations are platform-specific. We document the active Channel list (name, type, connected phone number or account) and recommend that the customer's admin re-establish WhatsApp Business API connections in Salesforce using the Messaging for In-App Messaging or WhatsApp on Cloud API setup, or through an AppExchange solution such as Movius or 7th Street.io.

Sanoflow Flows are the core automation unit and have no documented export endpoint. We extract Flow metadata during scoping: Flow name, trigger type, step count, action types (send message, assign agent, update field, add tag, create Enquiry), and any conditional branching logic. This is delivered as a Workflow Specification Document describing each Flow in sufficient detail for the customer's admin or a Salesforce consultant to rebuild in Salesforce Flow. Active Flows are not migrated as code.

Sanoflow Custom Fields on Contacts and Enquiries (Growth tier and above) map to Salesforce custom fields on Lead, Contact, Account, or Case respectively. We preserve the field label, field type (text, number, date, choice/picklist), and all field values. Choice-field options become Salesforce picklist values. Custom Field definitions are created in the destination org via Salesforce metadata API before data import begins.

Sanoflow Enquiry Forms are inbound entry points that generate Enquiry records. Form field definitions are migrated as metadata documenting the field structure and routing rules. The actual form hosting does not transfer between platforms. We recommend Salesforce Web-to-Lead (native, free) or a Salesforce Experience Cloud form as the replacement, and document any form-to-Flow routing rules in the Workflow Specification Document.

Sanoflow Teams and role assignments govern which agents manage which Enquiries. We extract team membership and role names and map them to Salesforce User records with appropriate Profiles (e.g., Sales Rep, Support Agent) and Permission Sets. Where Sanoflow roles have custom permission granularity not representable in standard Profiles, we recommend Permission Set Groups as the equivalent. Agent assignment on migrated Enquiries uses the mapped User records.

WhatsApp Broadcast records migrate as Salesforce Campaign metadata (Campaign Name, type, status, audience segment description). The actual message template content is documented but the WhatsApp template approval status does not transfer. Every active WhatsApp message template is flagged with its current content, Meta Business account association, and submission date for re-approval in the new WhatsApp Business account. Re-approval timelines from Meta typically run 24-48 hours and will delay campaign continuity.

Webhook configurations in Sanoflow (Premium and Enterprise only) point to destination-specific URLs and cannot be transferred. We document each active Webhook configuration: trigger event type, target URL, payload structure, and authentication method. The customer's admin re-creates Webhook endpoints in the destination platform post-migration, or a Salesforce Flow outbound message or Platform Event is used as the equivalent.