Migrate from Jelly to Zoho Desk

Jelly's shared email addresses are the top-level container for all conversations. We map each Jelly shared address to a Zoho Desk Department. The Jelly tier limits teams to 3 addresses ($29/month); Royal Jelly removes the cap ($69/month). We confirm address count during scoping and create a Department in Zoho Desk for each address, preserving the address itself as the department's outgoing email alias. The Zoho Desk Department is the structural root for ticket routing, agent assignment scope, and SLA policy binding. Fields migrated: shared address email string becomes Department primaryEmail field; department display name derived from address local-part.

Jelly conversations map directly to Zoho Desk tickets. Each conversation thread becomes one ticket with threaded comments. We map the conversation subject (first message subject line) to Zoho Desk ticket Subject; conversation state (open/closed) to ticket Status; first message timestamp to ticket Created Time; last message timestamp to ticket Modified Time. Jelly conversation assignments (single team member) map to Zoho Desk ticket Assigned To via the agent email lookup. Conversation metadata (Jelly inbox ID, original shared address) is preserved in custom fields jellyConversationId__c and jellySharedAddress__c. Required Zoho Desk fields: Subject (required), Department (required for department-scoped tickets), Status. Fields migrated: Subject, Description (first message body), Status, Priority, Due Date, Created Time, Modified Time, Assigned To (agent lookup).

Jelly conversation message history (inbound and outbound replies) maps to Zoho Desk Ticket Threads. We preserve message authorship by mapping Jelly sender email to Zoho Desk thread Author (resolved against the Contact record), and message content to thread Content. Thread direction (inbound/outbound) is stored as a custom field threadDirection__c on the thread record because Zoho Desk threads do not have a native direction flag. Message timestamp maps to thread Created Time. Threads are inserted in chronological order. Fields migrated: Content (message body), Author (email resolved to Contact), Created Time, threadDirection__c (custom field for direction).

Jelly team members are identified by email and conversation assignment, with no formal user directory API. We extract all distinct email addresses from conversation assignments and conversation creator metadata, then resolve each against the Zoho Desk agent list. Matching is performed by email address. Any Jelly team member without a corresponding Zoho Desk agent is flagged for the customer's admin to provision before the agent assignment phase. Jelly's flat team model has no role or permission hierarchy, so we default migrated agents to the Support Agent role in Zoho Desk and note any role escalation requirements during scoping. Fields migrated: email (resolved to agentId), Full Name (from Jelly assignment display name), Role (default Support Agent).

Jelly conversations can be assigned to a single team member. We preserve this as the Zoho Desk ticket Assigned To field by resolving the Jelly assignee email against the migrated agent list. Jelly's flat inbox has no department-level routing rules, so we assign all migrated tickets to the Department derived from the conversation's shared email address during import. If a conversation was unassigned in Jelly, the ticket is created with Assigned To left null and is flagged for manual routing. Fields migrated: agent email lookup to ticket Assigned To; Department assignment from shared address.

Jelly conversation states (Open, Snoozed, Closed) map to Zoho Desk ticket Status values. We create a custom Status mapping during migration scoping: Jelly Open maps to Zoho Desk Open, Jelly Snoozed maps to Snoozed (custom status if enabled), Jelly Closed maps to Resolved or Closed depending on Zoho Desk edition configuration. Status probability migration is not applicable because Jelly does not expose a probability model. Fields migrated: conversation status string to ticket Status picklist value.

Jelly conversations do not create explicit contact records; the requester is identified by the inbound message sender email address. We extract distinct sender emails from all conversation messages and create Zoho Desk Contact records. Required Zoho Desk Contact fields are Last Name and Email; where Jelly provides only an email address with no display name, we derive Last Name from the email local-part. Duplicate contacts (same email appearing across multiple conversations) are deduplicated by email address during import. Accounts are created as generic Organization records (Contact AccountName derived from the email domain) to satisfy the Contact-to-Account lookup requirement. Fields migrated: email (required), Last Name (derived from email local-part when no display name available), phone (extracted from message signature if present).

Jelly supports conversation tagging but does not expose tags via any documented API. We attempt to extract tags from IMAP headers (X-Label or IMAP flags) if IMAP access is scoped and the labels are set by Jelly. Where tags are not accessible via IMAP, they are excluded from migration scope and documented as a gap in the migration report. If IMAP labels are available, we create tags in Zoho Desk and associate them with the corresponding tickets via the tag association API. We cannot guarantee completeness of tag extraction; any tag derived from IMAP headers is flagged as IMAP-sourced in the delivery notes. Fields migrated (conditional): Tag Name (from IMAP label), Tag Association to ticket (via Zoho Desk tag API).

Jelly surfaces email attachments inline within conversations but does not expose an attachment storage endpoint. We attempt to pull attachments from the underlying IMAP connection (via IMAP FETCH with the BODY[] flag) if IMAP access is scoped. Attachments are stored as Zoho Desk ticket Attachments linked to the corresponding ticket thread. Inline images referenced in message bodies are handled separately as ContentDocument records attached to the ticket. If IMAP does not expose attachment data, attachments are excluded from scope and documented as a gap. We assess IMAP attachment capability during scoping and include a note in the estimate if full attachment recovery is not achievable. Fields migrated (conditional): Attachment file name, MIME type, binary content, linked to ticket thread ID.

Jelly stores metadata that has no native Zoho Desk equivalent, including the conversation's originating shared email address, Jelly's internal conversation ID, and the IMAP UID of the source message. We create custom fields in Zoho Desk during schema setup to preserve this context: jellyConversationId__c (text) stores the Jelly conversation identifier; jellySharedAddress__c (email) stores the originating shared address; jellyImapUid__c (number) stores the IMAP message UID for reconciliation. Royal Jelly metadata (Slack channel notifications, Royal Jelly tier flags) is excluded because it is either a live integration bridge (Slack) or associated with an undelivered roadmap feature. Fields migrated: jellyConversationId__c, jellySharedAddress__c, jellyImapUid__c (custom fields created in Zoho Desk).

Jelly has no explicit Account or Company object. We derive Account records from the requester email domain during Contact creation. Each unique email domain appearing across Contact records generates one Zoho Desk Account with the domain name as Account Name. Accounts are created before Contacts to satisfy the Contact-to-Account lookup. For accounts where the requester domain is a free email provider (gmail.com, yahoo.com), we create a generic Account named 'Individual Requesters' and attach all free-domain Contacts to it to avoid inflating Account count with single-contact records. Fields migrated: Account Name (derived from domain), Website (domain prefix with https://).

Royal Jelly lists enhanced contacts, stats and reporting, and sent-mail sync as forthcoming features. These are not yet shipped with a stable API schema or user-facing object model. We explicitly exclude any data associated with these features from migration scope to avoid silently dropping data that does not yet exist in Jelly or has no migratable export path. The Royal Jelly Slack integration is a live notification bridge with no stored schema; it does not migrate. We document the exclusion of each roadmap feature in the migration scope letter and recommend the customer's admin evaluate Zoho Desk equivalents (Zoho Desk Analytics for reporting, Zoho CRM integration for enhanced contact management) post-migration. Fields migrated: None — Royal Jelly roadmap features excluded from scope until shipped.