Migrate from Thena to Salesforce Service Cloud

Thena Requests are the primary ticket object and map directly to Salesforce Case. The Request Subject maps to Case Subject, Description to Description, Source to Case Origin, Status to Case Status, and Priority to Case Priority. Thena's AI-generated Sentiment and Urgency fields migrate as custom text fields (thena_sentiment__c and thena_urgency__c) on Case where present. The Thena request number migrates as thena_request_id__c for cross-reference. Sub-statuses under each main Status (Open, In progress, On hold, Closed) map to Case Status picklist values that we configure during Salesforce schema setup.

Thena Accounts map to Salesforce Account. The Thena account domain and name map to Account Website and Name respectively. Thena does not have a separate Contact object as a first-class record type; contacts live as requester data within or alongside Accounts. We create Salesforce Contacts for every unique requester email found on Requests and link them to the Account via AccountId. This 1:N relationship between Account and Contact is constructed at migration time from the requester resolution pass.

Thena Users export via GET /rest/v2/users with email, name, and role. We match by email against the Salesforce destination org's User table. Any Thena User without a matching Salesforce User enters a reconciliation queue for the customer's admin to provision before Case and Activity import resumes. Active and inactive status is preserved in a thena_user_active__c custom field on User.

Thena Conversations under Requests via GET /rest/v2/requests/{id}/conversations migrate to Salesforce EmailMessage records linked to the parent Case via ParentId. We reconstruct the message thread with sender, recipient, timestamp, body, and attachments preserved. Internal-only messages (marked private in Thena) are flagged with the HasBeenOpenerated flag on EmailMessage. Slack channel thread references that exist only as channel message IDs are stored in a thena_thread_ref__c custom text field because they have no Salesforce equivalent.

Thena custom fields are a first-class resource at GET /rest/v2/custom-fields. We retrieve the full schema during scoping and create matching custom fields on the Salesforce Case object (or Account if the custom field is account-scoped) before migration begins. Dropdown, boolean, date, number, and text types map to their Salesforce equivalents (Picklist, Checkbox, Date, Number, Text). Custom field values for every Request record are mapped during the Case insert phase.

Thena sub-statuses are per-workspace configurations under the four main statuses. We extract the full sub-status tree during scoping, map each unique sub-status value to a Salesforce Case Status picklist value, and configure the Status field picklist to include the full merged tree. We do not preserve the parent status hierarchy as a separate field by default; if the customer requires it, we add a thena_original_substatus__c custom field on Case to carry the exact source sub-status label for audit.

Thena Workflows built from Triggers, Conditions, and Actions (status change, assignee change, custom field change, Slack notification) do not migrate as code to Salesforce Flow because the automation models are structurally different. We export the workflow configuration as a structured JSON summary covering trigger type, conditions, actions, and the workspace it applies to. The customer's Salesforce admin or a certified partner uses this inventory to rebuild equivalent Flows in Salesforce after migration.

Thena Form definitions and field schemas export via the v2 API. Form submission data maps into Salesforce Case records based on the form-to-field mapping defined during scoping. We do not migrate the Form UI itself; the customer rebuilds form endpoints in Salesforce Experience Cloud or Web-to-Case based on the exported form schema. Form submission timestamps and responder data map to standard Case fields.

Thena captures the channel source for each Request (email, Slack, MS Teams, Discord). These map to Salesforce Case Origin picklist values. Email maps to Email, Slack maps to Web (with thena_channel__c set to Slack for reporting), MS Teams maps to Web (with thena_channel__c set to Teams), and Discord maps to Web (with thena_channel__c set to Discord). We document any unmapped source values during scoping for the customer's admin to extend the picklist.

Thena Request assignee (a User reference) maps to Salesforce Case OwnerId. We resolve OwnerId via the User email match computed in the User reconciliation phase. If the original assignee is inactive in Thena or has no corresponding Salesforce User, the Case is assigned to a designated migration queue User for the customer's admin to re-route post-migration.