Migrate from Desky to Salesforce Service Cloud

Desky Tickets migrate to Salesforce Case as the primary support record. Each Ticket's subject, description, status, priority, created date, and updated date map to Case Subject, Description, Status, Priority, CreatedDate, and LastModifiedDate. The mapping resolves the Ticket's linked Customer to a Salesforce Contact record and the linked Company to a Salesforce Account record before Case insertion. Custom ticket fields are detected during the source scan, custom fields are created in Salesforce (as text, picklist, or checkbox depending on content), and field values transfer directly. Tickets in closed states (Resolved, Closed) preserve their original status mapping so that Case history reflects the same resolution state.

Desky Customers map to Salesforce Contact. The customer's name, email, phone, and company association migrate directly. The Company-to-Account relationship is resolved during the Account migration pass so that Contact.AccountId is set at insert time. Any Desky Customer records without a company link create Contacts without an Account (unparented) and are flagged for the customer admin to resolve post-migration. Custom contact properties migrate to Salesforce custom fields on Contact where the destination org supports the field type.

Desky Company records map to Salesforce Account. The Company name becomes Account Name. Address fields (street, city, state, country, postal code) map to BillingAddress fields on Account. We use Account Name as the dedupe key during import and create Accounts before Contact import so that the Contact.AccountId lookup is satisfied at the moment of insert. Company records with no associated Customers still migrate as standalone Accounts and are flagged for manual review if the customer expects a different organizational structure at the destination.

Desky Agents map to Salesforce User records by email address match. We extract the full agent list from the Desky export and match each by email to the destination org's User table. Agents without a matching Salesforce User are held in a reconciliation queue; the customer's Salesforce admin provisions missing Users before the migration resumes. Agent role (Admin, Agent) maps to Salesforce Profile and Role assignments based on a mapping table agreed during scoping.

Desky KB Articles migrate to Salesforce Knowledge (Knowledge__kav object). The article title maps to ArticleTitle, body content to ArticleBody, publication status to ValidationStatus (Published, Draft, Archived), and category to DataCategoryGroup selections. HTML formatting within article bodies may require sanitization before import to prevent rendering issues in Salesforce Lightning. Articles with embedded images are flagged for manual re-embedding as Salesforce stores inline images as ContentDocument references. Draft articles migrate as draft Salesforce Knowledge articles; the customer admin publishes them post-migration.

Desky Tags are lightweight label strings attached to Tickets and Articles. We extract all unique tags from the export and apply them as either Salesforce Topics (via TopicAssignment records linked to Case or Knowledge article) or as a custom multi-select picklist on Case, depending on the destination org's configuration. The customer chooses the tagging strategy during scoping. Tag-to-topic mapping is stored as a lookup table for audit and rebuild reference.

Desky ticket and article attachments are stored as file URLs in the CSV export. We download all referenced files, preserve original filenames and MIME types, and re-upload them to Salesforce as ContentVersion records (file blob) linked to the parent Case via ContentDocumentLink. Files over 25 MB are flagged individually because Salesforce has a 25 MB per-file upload limit via API. Tickets with more than 10 attachments are flagged upfront so the customer can decide whether to proceed with automated re-attachment or handle them manually. The re-attachment pass runs as a separate post-import job after all Cases are inserted.

Desky supports user-defined fields on Tickets beyond the standard set (subject, description, status, priority, assignee). We detect all custom fields during the source scan, infer Salesforce field types from the data content (text, number, date, checkbox, picklist), and create matching custom fields on the Case object in Salesforce before migration begins. Fields that cannot be typed confidently from content analysis are flagged for the customer's admin to define before the migration phase starts.

Desky ticket conversation threads contain agent and customer replies with timestamps and author attribution. These migrate to Salesforce as EmailMessage records linked to the Case, preserving the original sender email, timestamp, and body text. Internal agent comments flagged as private in Desky migrate to CaseComment with CommentType=Private. Thread ordering is preserved by the EmailMessage MessageDate field.

If the destination org does not use Salesforce Topics, we apply Desky tags as Case Tag records (the legacy tagging model) which appear in the Case Tags related list in Lightning. This is a fallback option discussed with the customer during scoping. Tag cardinality is checked against the destination org's tag limits per object.