Migrate from Experia to Salesforce Service Cloud

Experia Tickets map to Salesforce Case as the primary service object. Standard ticket fields (subject, body, status, priority) map to Case Subject, Description, Status, and Priority. We resolve the Experia ticket ID as a custom field exp_ticket_id__c for reconciliation. The Case Origin maps from the Experia channel field (email, chat, web) to Salesforce Case Origin picklist values configured during schema setup.

Experia Customer records map to Salesforce Contact. Contact fields (name, email, phone, address) migrate directly. We set the Contact's Email field and use it as the dedupe key during import. Any Experia customer without an associated Company maps to a standalone Contact; customers with a Company link resolve AccountId at migration time after Account records are created.

Experia Company records map to Salesforce Account. The company name maps to Account Name, and domain data maps to Website. Account is created before Contact import so that the AccountId lookup is satisfied at Contact insert. Multi-contact deduplication logic is confirmed with the customer during scoping because Experia's company-contact association model may differ from Salesforce's strict Account-Contact hierarchy.

Experia Agent records map to Salesforce User. We resolve agents by email match against the destination org's User table. Any Experia Agent without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision. Agent role and permission level (admin, agent, supervisor) maps to Salesforce Profile and Role assignments that we confirm during scoping.

Experia Teams map to Salesforce Case Queues. Team membership migrates as QueueMembership records. The queue-based routing model in Salesforce requires configuring queue-case assignment rules during schema design, which we handle before production migration. This is a configuration step that depends on the customer's desired routing logic.

Experia Conversation threads attached to Tickets migrate to Salesforce EmailMessage records linked to the Case. Each message in the thread becomes a separate EmailMessage with the sender, recipient, body, and timestamp preserved. The thread ordering is maintained by the EmailMessage MessageDate field. Inbound and outbound direction is inferred from sender address matching the Contact or Agent email.

Experia custom ticket fields are undocumented, so we treat them as unknown until we receive a field inventory from the customer or obtain read access to the Experia admin panel. We create custom fields on the Salesforce Case object with API names matching the Experia field names where discoverable. Field types (text, picklist, number, date) are inferred from value patterns during discovery or explicitly confirmed by the customer. Custom fields are created before Case migration begins.

Files attached to Experia Tickets or Conversations migrate as Salesforce ContentVersion records linked to the Case via ContentDocumentLink. We perform size and format validation during ingestion; files over 25 MB require chunked upload via the Salesforce ChunkedUploads resource. Attachment count and total volume are confirmed during discovery because large file libraries extend migration timelines significantly.

Experia Tags that categorize Tickets and Customers map to a Salesforce custom field on Case. We use either a custom multi-select picklist (if tag cardinality is low, under 150 values) or Salesforce Topics with TopicAssignment records (if tag taxonomy is broad). The customer chooses the strategy during scoping, and we apply it during the transform phase.

Experia ticket timestamps (created_at, updated_at, closed_at) migrate to Salesforce Case CreatedDate, LastModifiedDate, and a custom closed_date__c field. To enable CreatedDate and LastModifiedDate migration, we enable 'Set Audit Fields upon Record Creation' and 'Update Records with Inactive Owners' permissions in the destination org before migration. These are Salesforce admin steps we coordinate with the customer's Salesforce admin.

Experia's integrated chatbot logic has no direct Salesforce equivalent. We document the chatbot's decision trees, trigger conditions, and response flows during discovery as a written handoff. The customer's admin or a Salesforce implementation partner rebuilds this as an Einstein Bot or a Flow-based bot. Chat history from chatbot sessions does not migrate as structured records unless Experia exports it as conversation logs, which we ingest as Case Comments or EmailMessages.

Experia workflow automation rules (auto-assignment, status changes, notifications) have no migration path as code. We perform a discovery audit of all active rules and deliver a written inventory with trigger conditions, actions, and recommended Salesforce Flow equivalents. The customer's Salesforce admin or a certified Salesforce partner rebuilds each rule in Flow post-migration.