Migrate from Octadesk to Salesforce Service Cloud

Octadesk Tickets map to Salesforce Cases as the primary service record. We preserve Ticket status, priority, origin (email, WhatsApp, chat, social), and requester metadata as standard Case fields. Octadesk's channel metadata (source_channel, channel_id) migrates as custom fields on Case. We resolve the Case's ContactId by matching the Octadesk requester contact email against the migrated Contact record. If the destination org uses Service Cloud Professional or above, we configure Case Record Types to mirror Octadesk's ticket categories or pipelines.

Octadesk Tickets store custom fields as an array of objects (customField with key, value, and type properties) rather than flat key-value pairs. We parse each array entry, map it to a typed Salesforce custom field on Case (text, number, date, picklist, or checkbox), and validate type compatibility before insert. Any field with a data type mismatch (e.g., a date stored as a string) is flagged for manual review during scoping. This flattening step is the most schema-intensive part of the migration and must be completed before any Case data is loaded.

Octadesk Chats represent real-time conversation sessions that must be preserved as readable thread history in Salesforce. We export Chat messages via GET /chat with sequential pagination (100 items per page) and reconstruct each Chat as a Case Comment or EmailMessage thread linked to the corresponding migrated Case. Channel metadata (WhatsApp, Instagram, Facebook Messenger, webchat) is preserved in a custom field case_channel__c on the Case. Accounts with very high chat volumes may require extended export windows due to the 100-item page cap; we chunk exports into manageable batches and resume from the last cursor on transient failures.

Octadesk Contacts migrate directly to Salesforce Contacts. We use the contact email as the dedupe key during import. Standard fields (name, phone, email, lifecycle data) map to their Salesforce equivalents. Any Octadesk custom contact properties are flattened to Salesforce custom fields on Contact using the same array-parsing approach as Ticket custom fields. Contacts are loaded before Cases so that the ContactId lookup is satisfied at Case insert time.

Octadesk Companies map to Salesforce Accounts. The company domain becomes the Account Website field and is used as a secondary dedupe signal alongside email. Account is created before any Contact import so that the AccountId lookup is resolved on Contact insert. If the destination org uses Person Accounts, we discuss the account model strategy with the customer during scoping because it affects how Contact and Account objects are provisioned.

Octadesk Agents are migrated as Salesforce Users. We resolve Agents by email match against the destination org's User table. Any Octadesk Agent without a matching Salesforce User is held in a reconciliation queue; the customer's admin provisions missing Users before record import resumes. Agent role information from Octadesk (admin, agent, supervisor) maps to Salesforce Permission Sets or the customer's existing role hierarchy.

Octadesk Teams map to Salesforce Queues for case assignment routing. We preserve team membership during migration and configure Queue membership based on the Octadesk team membership list. If the customer uses Skills-Based Routing in Salesforce (Omni-Channel Professional or above), we map Octadesk team specialisations to Salesforce Skills. Queues are provisioned in the destination org before Case migration begins.

Tags from Octadesk Tickets migrate as a Salesforce multi-select picklist field on Case. We normalise tag names to comply with Salesforce picklist restrictions (no special characters, length limits). If the customer uses Salesforce Topics, we discuss migrating tags to TopicAssignment records instead; the customer chooses the strategy during scoping.

Attachments on Tickets and Chats are downloaded from Octadesk (stored as URL references) and re-uploaded to Salesforce as ContentDocument records linked via ContentDocumentLink to the corresponding Case. We validate attachment integrity with hash comparisons post-upload. Large file attachments (>25 MB) may require Salesforce Content workspace provisioning or an AppExchange document management tool.

Octadesk automation rules (triggers, macros, routing logic) reference internal agent IDs, team IDs, and custom field values by internal identifier and have no public export API. We do not migrate automations as code. We produce a written automation audit report during scoping that lists every Octadesk rule with its trigger conditions, actions, and a recommended Salesforce Flow or Omni-Channel equivalent. The customer's admin or a Salesforce partner rebuilds the automations post-migration. This limitation applies to all Octadesk migrations regardless of destination platform.

Octadesk's proprietary AI agent and chatbot flow configurations are built on internal schemas not exposed via public API. We do not migrate them. We deliver a structured export of the Octadesk chatbot flow metadata (as JSON if accessible via the UI export) and a written recommendation for Einstein Bots or a third-party chatbot platform on Salesforce. This is a significant rebuild scope that the customer should plan separately.