Migrate from Dixa to Salesforce Service Cloud

Dixa Conversations map to Salesforce Cases as the primary migration record. Each conversation carries a unique Dixa ID preserved as a custom field dixaconversationid__c for audit and cross-reference. Channel type (phone, email, chat, social) maps to a custom Case Origin picklist that the customer's admin configures before migration. Conversation priority and customer tier from Dixa become custom Case priority fields or field updates. Closed date and status migrate as Case ClosedDate and Status respectively.

Dixa Messages are children of Conversations and migrate as Salesforce EmailMessage records linked to the parent Case. Each message references its parent conversation ID, which we resolve to the Salesforce Case ID during the message load phase. Outbound agent messages and inbound customer messages both migrate with the original timestamp preserved as EmailMessage.Incoming_Rfc_822_Date__c or a custom field. Messages without a resolvable parent Case are flagged as orphaned and held for manual assignment.

Dixa Customer profiles map to Salesforce Contact records attached to the relevant Account. Customer email is the primary dedupe key; existing Salesforce Contacts with matching email receive conversation history appended rather than a duplicate record created. Custom properties on the Dixa customer profile migrate to custom Contact fields created during schema setup. Order history integration data from Dixa's Shopify or Magento connector migrates as a note attachment or custom text area if the CRM integration is not live at migration time.

Dixa Agents map to Salesforce User records by email match. During migration, we extract every distinct agent email referenced on conversations and messages and match against the destination org's User table. Any Dixa Agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Agent-to-team assignments from Dixa migrate as Salesforce Group membership or Role assignments depending on the customer's chosen org structure.

Dixa Teams map to Salesforce Groups (for visibility and sharing) and Salesforce Queues (for case assignment routing). Team names and member lists migrate cleanly, but team-level SLA settings, operating hours, and queue configurations require explicit rebuild in Salesforce Omni-Channel. We document the current Dixa team structure as a deliverable for the customer's admin to translate into Salesforce Queue and Routing Configuration.

Dixa auto-tags conversations for routing intent regardless of channel. These tags reflect internal queue logic and customer priority, not external-facing labels. We map routing-intent tags to a Salesforce custom multi-select picklist field on Case (dixaroutingintent__c) for reporting and segmentation. If the customer uses Dixa tags for content classification, we map them to Salesforce Topics with TopicAssignment records. Direct one-to-one mapping is rarely possible because Dixa's auto-tag taxonomy is platform-specific; the customer chooses the target strategy during scoping.

Dixa custom fields on conversations surface as named columns in the CSV export. We map each custom field to a Salesforce custom Case field of equivalent type (text, number, date, picklist) created during schema setup. Field-level security and page layout assignments require the customer's Salesforce admin to configure after migration. Custom fields with picklist-type values in Dixa require a value mapping table because Salesforce picklists are org-wide enumerated values.

Dixa post-conversation CSAT ratings migrate as custom fields on the parent Case: csatscore__c (numeric), csatsubmitteddate__c (timestamp), and csatlinkedconversation__c referencing the Dixa conversation ID. Ratings without a linked conversation are flagged as orphaned and reported separately. We do not migrate CSAT to Salesforce's native Satisfaction Rating object because that object is tied to Salesforce's own survey mechanism rather than imported external ratings.

Dixa Knowledge Base articles migrate as Salesforce KnowledgeArticleVersion records. Article title, body content, and category metadata map to Salesforce article fields. We handle articles as standalone migration objects rather than attachments. Articles tied to specific Dixa routing flows are noted in a separate mapping table since the flow-to-article linkage does not migrate. Article types in Salesforce must be configured before migration to match Dixa's category structure.

Dixa channels (Phone, Email, Chat, Facebook Messenger, Instagram, Twitter, WhatsApp) store channel type as a field on each conversation record. We map these to Salesforce Case Origin values, which include standard values like Phone, Email, and Web plus custom values for social channels. WhatsApp and Instagram channel support in Salesforce requires the Messaging Sessions feature, which is a separate licensing consideration.