Migrate from Cordial to Salesforce Sales Cloud

Cordial Contacts map to Salesforce Lead or Contact depending on whether they represent an unqualified prospect or a known organization member. We use Cordial's channel subscriptions and any lifecycle-related custom attributes to determine the split. Unqualified email subscribers with no associated company map to Salesforce Lead; Contacts with a known organization and purchase history map to Salesforce Contact with AccountId resolved. The original Cordial contact key is preserved in a custom field cordial_contact_key__c for audit and cross-reference.

Cordial's flat attribute schema means each custom contact property (e.g. loyalty_tier, preferred_store, acquisition_source) maps to a Salesforce custom field on the appropriate object. String attributes map to Text(255) or Text Area; numeric attributes map to Number; geo attributes map to geolocation or Address components. We create the destination schema in a Sandbox before migration and validate field types against Salesforce field limits (1,024 character limit per custom text field).

Cordial stores some properties as arrays (e.g. favorite_colors, purchase_history, behavioral_tags). Arrays do not have a direct Salesforce equivalent. We normalize them during transformation: multi-value arrays with fewer than 150 unique values become Salesforce Multi-Select Picklist; high-cardinality arrays become a related custom object with a lookup to the parent Contact and one row per array value. The normalization strategy is agreed upon during scoping and documented in the mapping specification.

Cordial Lists are static sub-collections of Contacts. We export list membership as a Campaign with Campaign Type = Marketing List and add each list member as a CampaignMember with Status = Sent. For organizations that prefer a pure list model, we offer a custom Cordial_Lists__c object with a lookup to Contact and a List_Name__c field, which is simpler to query but breaks standard Campaign reporting. The customer chooses during scoping.

Cordial Segments are dynamic rule-based audiences built from contact attributes and event conditions. Segment definitions are not API-exportable. We document each active segment with its rules, conditions, and estimated match count at migration time, then deliver a written segment inventory to the customer's admin for manual rebuild as a Salesforce Campaign with filter criteria or as a Flow-based audience query. Segment membership at migration time is captured as a CampaignMember snapshot.

Cordial Products store standard fields (productID, productName, price) plus a variants array containing SKU and attribute pairs. We export products to Salesforce Product2 with ProductCode set to the root product ID, Name set to productName, and Description carrying the full JSON for reference. The variants array is processed separately (see Variant mapping below).

Cordial product variants (color, size, SKU) are nested JSON arrays under a single product record. We unpack the variant array and generate one Salesforce Product2 record per SKU, preserving the parent Cordial product ID in a custom field parent_product_id__c. Variant-level pricing (if stored) maps to StandardPricebook2 entries per SKU. If the destination prefers a single product with variant attributes, we use Salesforce's Quantity Scheduling or Product Attribute Sets instead, agreed upon during scoping.

Cordial Channels are sub-attributes on Contact indicating opt-in status per channel. We map email opt-in to Salesforce HasOptedOutOfEmail (false = opted in, true = opted out, per Salesforce convention). SMS and push opt-in status migrate to custom fields sms_opt_in__c and push_opt_in__c as boolean. Channel-level preferences (e.g. preferred_send_time) become custom fields on Contact.

Cordial supports custom event types stored as behavioral events on contacts (purchases, abandoned_cart, page_view, etc.). Events are not first-class objects in Cordial's API but are accessible via the Contact Activity Export API with time-range filters. We export events as Salesforce Task records with TaskSubtype = Custom and a custom event_type__c field distinguishing the event type. High-volume event types (e.g. page_view) can be summarized and stored as custom fields on Contact rather than individual Task rows to avoid Salesforce storage limits.

Orders are not a native first-class object in Cordial's core schema but are often stored as custom attributes on contacts or linked via event data with event_type = purchase. We identify order-related attributes (order_id, order_total, order_date) and custom event types during schema discovery, then design a custom Cordial_Order__c object in Salesforce with fields for order_id, contact_lookup__c, order_total__c, order_date__c, and a related Cordial_Order_Item__c object for line items. If order data is sparse, we may store it as custom fields on Contact instead. This is determined during discovery.

Cordial Message Analytics (opens, clicks, bounces, unsubscribes) are available via the Message Analytics Export API. We map these to Salesforce CampaignMember Status values (Sent, Delivered, Opened, Clicked, Unsubscribed, Bounced) on the corresponding Campaign. Aggregate metrics (open rate, click rate per campaign) are stored as custom fields on the Campaign for reporting. Message experiment results (A/B test variants and winner data) are NOT exportable via API and must be manually exported from the Cordial UI before migration cutover; we flag this gap during scoping.

Cordial Programs organize campaigns and automation sequences but are not API-exportable. We document each active Program with its trigger conditions, steps, delays, and channel actions as a written specification. The customer's Salesforce admin or a Salesforce partner rebuilds these as Salesforce Flow (record-triggered, scheduled, or screen flow variants). The program documentation includes a trigger recommendation (e.g. Lead-created, Contact-field-changed, scheduled) and a step-by-step rebuild guide. This is a manual handoff, not an automated migration.

Cordial Owners are referenced on Contact, Product, and Engagement records. We resolve Owners by email match against the Salesforce destination org's User table. Any Cordial Owner without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId is required on standard Salesforce objects, so this step gates the production migration.