Migrate from Jelly to Salesforce Service Cloud

Jelly Conversations map to Salesforce Case records. The entire email thread — all inbound and outbound messages in the conversation — migrates as a series of Salesforce EmailMessage records linked to the Case, preserving chronological order via CreatedDate and the thread subject as the Case Subject. The shared email address that received the message becomes the Case Origin. Jelly conversation status (open/resolved/archived) maps to Salesforce Case Status values that we configure as a custom status field picklist on Case.

Each Jelly shared email address becomes a Salesforce Email-to-Case address in Setup > Email-to-Case. We configure the routing email address at migration time so that new inbound emails to the shared address automatically create Cases in the destination org. Existing Jelly conversations are bulk-loaded against the matching Case records and the EmailMessage thread structure.

Jelly team members are identified by email address and conversation assignments. We map each Jelly team member email to a Salesforce User record by email match. If a Salesforce User does not yet exist for a Jelly team member, we flag it in the owner reconciliation queue and the customer's admin provisions the User before Case import begins. Jelly-assigned conversations carry the assignee as a custom Case field (jelly_assignee_email__c) until the User lookup is confirmed.

A Jelly conversation is assigned to a single team member. In Salesforce, Cases use OwnerId to assign to Users or Queues. We resolve Jelly assignee emails to Salesforce User IDs and set Case.OwnerId during import. If the customer uses Salesforce Queues for routing (common with omni-channel), we configure the queue mapping during scoping and set OwnerId to the target Queue ID instead of a User ID.

Jelly threads contain customer email addresses without a formal contact record. We extract unique sender addresses from all EmailMessage records, resolve them against the Salesforce Contact table by email, and create Contact records for any new addresses. Contacts are linked to Accounts using domain-based matching or customer-provided Account assignments. This is a N:1 merge because a single customer's thread history (multiple conversations) produces one Contact record in Salesforce.

Jelly supports conversation tagging but exposes no tags via any documented API. If the customer has Jelly IMAP access, we attempt to extract tags from email header metadata (X-Label or custom IMAP flags) where present. If tags are available, we create a Salesforce custom multi-select picklist field (jelly_tags__c) on Case and populate values during import. If IMAP headers are unavailable, tags are listed as a documented gap in the scope. Tags are excluded from migration guarantee unless a reproducible extraction path is confirmed during scoping.

Jelly surfaces email attachments inline within conversations but exposes no attachment storage API. If the customer has IMAP access configured for the shared mailbox, we attempt to extract attachment blobs from the IMAP BODY[] fetch where supported by the mail server. Attachments migrate as Salesforce ContentVersion records with a ContentDocumentLink to the parent Case. We note in every estimate that IMAP-based attachment recovery is server-dependent and may be incomplete for some mailbox configurations; explicit customer sign-off on attachment recovery scope is required before this phase begins.

Royal Jelly's Slack integration is a live notification bridge that posts alerts to a Slack channel when new Jelly conversations arrive. This is a streaming notification configuration, not stored data, and has no exportable schema. We do not migrate Slack integration settings. We document the integration in the handoff inventory so the customer's admin can configure a new Slack integration in Salesforce using Salesforce for Slack, Flow-based Slack notifications, or a native Salesforce+Slack Connected App post-migration.

Enhanced Contacts is listed as forthcoming in Royal Jelly but has not been shipped. No stable schema exists for this feature, so it cannot be migrated as a data object. We explicitly exclude it from scope until Jelly ships it with a documented API. The customer can recreate any desired contact enrichment fields as Salesforce custom fields on Contact post-migration.

Stats and reporting are listed as forthcoming in Royal Jelly. Aggregated analytics and reporting aggregates are not migratable data objects regardless of platform. We do not attempt to migrate Jelly analytics. The customer's admin builds new Service Cloud reports and dashboards post-migration using migrated Case data as the source.