Migrate from Yuma AI to Salesforce Service Cloud

Yuma Tickets (the primary record in the host helpdesk) map to Salesforce Case. The ticket body, subject, status, priority, and created/updated timestamps migrate directly. Yuma's resolution status flag (resolved_by_ai, resolved_by_agent, escalated) maps to a custom Case field yuma_resolution_type__c so the destination AI can use this signal for retraining or classification. Custom ticket fields from the host helpdesk (order_id, return_reason, subscription_tier) migrate to custom Case fields of equivalent Salesforce field types.

Customer profiles from the host helpdesk map to Salesforce Contact. The customer's name, email, phone, shipping address, and order history summary migrate as Contact fields. Yuma-specific customer identifiers are stored in a custom field yuma_customer_id__c for reference. If the host helpdesk uses a Company/Organization model, those map to Salesforce Account and the Contact gets an AccountId lookup relationship.

Company records from the host helpdesk (e.g., Zendesk Organizations) map directly to Salesforce Account. The company domain becomes the Account Website field and serves as the dedupe key during import. Account is created before Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

Every message in a ticket thread migrates as an EmailMessage record linked to the Case. Messages authored by a Yuma Auto-Pilot are flagged with a custom field message_author__c = 'Yuma_AutoPilot' so the destination can use the AI-authored corpus for retraining. Human agent replies are flagged as message_author__c = 'Human'. Thread ordering is preserved by setting EmailMessage.MessageDate to the original timestamp. Attachments migrate as ContentDocumentLink records attached to the EmailMessage.

Yuma Auto-Pilot agents are a logical routing layer, not direct 1:1 maps to human agents. We export all Auto-Pilot agent configurations as structured JSON including escalation rules, trigger conditions, and routing logic. For human agents who worked alongside Yuma, we map by email to Salesforce User. Yuma's escalation routing rules are documented and mapped to Service Cloud Omni-Channel Routing Configurations or Assignment Rules during the configuration phase.

Yuma routes edge-case tickets to specific human teams via Flow rules. We map these team assignments to Salesforce Queues (for case ownership) and Omni-Channel Routing Configurations (for skills-based routing). Teams that exist only in Yuma (e.g., a Yuma-specific AI ops team) are flagged for the customer's admin to resolve in Service Cloud, since Service Cloud's routing model is team-plus-skills rather than Yuma's rule-plus-escalation model.

Inline attachments on tickets (images, PDFs, order screenshots) migrate via Salesforce ContentDocument and ContentVersion. Yuma does not store its own attachment blob — attachments live in the host helpdesk API, which we query as part of the helpdesk export. ContentDocumentLink attaches each file to the parent Case record.

Yuma applies internal tags during ticket processing (resolution_type, automation_status, channel). We export all tags alongside the ticket record. Tags that represent business categories (return_reason, product_line) map to Salesforce Case custom multi-select picklist fields. Operational tags (automation_status) are preserved in a custom field yuma_tags__c for reference and potential future segmentation.

Custom fields from the host helpdesk (order ID, return reason, subscription tier, ecommerce-specific metadata) map to Salesforce Case custom fields of matching types. We pre-create the destination schema before migration so all custom fields exist before any records load. Field-level security is set to Read/Write for the migration user during load and locked down afterward.

Guidelines are Yuma's brand policy rules that constrain AI behavior. We export them as structured JSON with full condition logic, action sets, and channel scope. Most destination platforms do not have a native equivalent to Guidelines. We deliver the exported JSON with a written recommendation for how to encode equivalent guardrails in Salesforce Flow (for process automation) or Knowledge Articles (for agent guidance). The rebuild is manual and scoped as a separate workstream.

Yuma Flows are visual workflow builders for ticket routing, triggers, and escalation sequences. We export Flow definitions as JSON with all conditions, actions, and delay steps. The target equivalent in Salesforce is Flow (record-triggered or scheduled) combined with Omni-Channel Routing. We deliver a written Flow inventory documenting each Yuma Flow's trigger, logic, and recommended Salesforce equivalent, with explicit notes on what cannot be replicated natively (e.g., real-time LLM-based condition evaluation). Manual rebuild by the customer's Salesforce admin is required.