Migrate from Desk365 to Salesforce Service Cloud

Desk365 Tickets map directly to Salesforce Case. The Ticket Status (Open, Pending, Resolved, Closed) maps to Case Status picklist values that we configure in the destination org. Priority from Desk365 migrates to Case Priority. Created and Updated timestamps preserve as Case CreatedDate and LastModifiedDate. Custom Fields on the Ticket (text, number, dropdown, date, boolean) map to equivalent Case custom fields that we pre-create in Salesforce before migration. If the destination org does not have equivalent custom field types, we flag them in the pre-migration reconciliation report for the customer to resolve.

Desk365 Customer records (name, email, company association, portal access status) map to Salesforce Contact. The Customer email address becomes Contact Email and serves as the deduplication key. Company association maps to an Account lookup; if the Desk365 Customer has no linked company, we create a single Account placeholder per customer to satisfy the Contact-Account relationship required by Salesforce. Portal access status migrates as a custom field on Contact rather than as a native access control since Salesforce governs portal access via Profile and Partner Community licensing.

Desk365 Agent records (display name, email, department membership, role Admin/Agent, active/inactive) map to Salesforce User. We match by email. Agents without a matching Salesforce User are held in a reconciliation queue while the customer's Salesforce admin provisions User records. Active/inactive status maps to the User IsActive flag. Desk365 role labels (Admin/Agent) map to Salesforce Profile assignments during provisioning; the customer's admin determines the appropriate Profile per role.

Desk365 Departments with configurable access levels (global, department-only, agent-only) translate to Salesforce Queues and Sharing Rule configurations. Each Desk365 Department becomes a Queue on Case, and we design Sharing Rules to restrict Case visibility to department members. If Desk365 used agent-only access levels, we implement a custom visibility field or Private Sharing Model on Case. This is a structural redesign, not a field copy, because Desk365 department membership is implicit in the ticket access model while Salesforce requires explicit Sharing Rule or Queue configuration.

Each Desk365 Ticket Conversation (public replies, internal notes, system-generated status changes) maps to Salesforce EmailMessage records linked to the parent Case. Public replies become EmailMessage with direction=Incoming or Outgoing. Internal notes migrate as CaseComments with IsPublished=false. System-generated status changes map to a custom CaseHistory field or as internal CaseComments. Chronological ordering is preserved by setting the EmailMessage CreatedDate to the original Desk365 timestamp. If Desk365 conversations include inline images, we extract them as ContentDocument records and re-embed them in the EmailMessage body.

Desk365 KB Articles (Draft, Published Agent-only, Published public) map to Salesforce Knowledge Articles. We export the publish status and visibility flag; Desk365 Agent-only articles land as Draft in Salesforce with a custom visibility__c field set to 'Agent Only'. Salesforce Knowledge supports Data Category groups for segmentation but does not have a native three-tier visibility model. The customer reviews Draft articles post-migration and sets the correct Data Category or publishes them manually. Folder structure from Desk365 does not map to Salesforce folder equivalents; we document the folder taxonomy for the admin to recreate in Knowledge.

Desk365 SLA Policies define First Response and Resolution time targets tied to Priority and Business Hours. These map to Salesforce Entitlement Processes with milestones. Each Desk365 SLA Policy becomes an Entitlement Process with two milestones: First Response and Resolution. Time targets in Desk365 hours map to Salesforce milestone elapsed hours. Desk365 Business Hours schedules map to Salesforce Business Hours linked to the Entitlement. Priority-based SLA assignment (Priority 1 = 1-hour response) maps to Entitlement Process entry criteria using Case Priority. This is a configuration migration, not a field copy, because Entitlement Processes require setup in Salesforce Setup rather than data import.

Desk365 Tags are flat string labels applied to Tickets. We preserve all Tag values. During migration, we apply them to a custom multi-select picklist field on Case (cstm_tags__c) if the total unique tag count is under 150 and all Desk365 tags fit a picklist model. If the tag vocabulary exceeds 150 unique values, we map them to Salesforce Topics with TopicAssignment records on Case. The customer selects the strategy during scoping.

File attachments on Desk365 Tickets (and inline in conversations) are stored as URLs pointing to Desk365 blob storage. We download each file and upload to Salesforce as ContentDocument, then attach to the parent Case via ContentDocumentLink. Original file names, MIME types, and sizes are preserved. If a file exceeds Salesforce's 25 MB per file limit (or the org's limits), we upload to the customer's connected cloud storage (SharePoint or Google Drive) and insert a link in the Case description.

Desk365 custom text, number, dropdown, date, and boolean fields on Tickets map to equivalent custom fields on Salesforce Case. We extract field definitions (name, type, options for dropdown) from Desk365 and create matching fields in Salesforce during pre-migration schema setup. If a Desk365 field type has no direct Salesforce equivalent, we flag it during discovery with the recommended Salesforce type and let the customer decide. Custom field values migrate with the Ticket as Case field values.

Desk365 Premium IT Asset Management links hardware/software assets to Tickets. Asset records and their Ticket associations migrate to Salesforce Asset objects linked to the parent Account and Contact. Asset-to-asset relationships and dependency graphs do not have a native Salesforce equivalent and require a custom object design during scoping. If the customer used Desk365 IT Assets heavily, we recommend a dedicated Salesforce implementation partner for the Asset data model post-migration.