Migrate from Atomicwork to Salesforce Service Cloud

Atomicwork Request maps to Salesforce Case as the primary ticket object. We map Request.id to Case.CaseNumber, Request.category to Case.RecordType, Request.status to Case.Status, Request.priority to Case.Priority, Request.requester_id to Case.ContactId via User lookup, and Request.assignee_id to Case.OwnerId. We preserve the AI-resolved versus human-resolved flag in a custom field ai_resolved__c on Case so that the customer's analytics on deflection rate continue post-migration. Conversation thread (comments, replies, system notes) migrates as EmailMessage records linked to the Case. Request.created_at and Request.updated_at map to Case.CreatedDate and Case.LastModifiedDate for historical timestamp preservation.

Atomicwork Users (agents and requesters) map to Salesforce Users. We resolve by email match during import. Agent status (active, inactive) maps to Salesforce User.IsActive, and role (IT agent, HR agent, Finance agent) maps to a custom User field user_type__c since Salesforce does not have a native ITSM role concept. Any Atomicwork User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before Case import begins.

Atomicwork Assets (CI items linked to Requests) map to Salesforce Asset by default, preserving Asset.Name, Asset.Type, Asset.Status, and the relationship to Case via AssetId. Asset Discovery scan data is NOT accessible via the Atomicwork API, so we request a manual Discovery export CSV from the customer during scoping and ingest it separately as a CMDB import. If the customer's CMDB is more complex than the standard Asset object, we create a custom CMDB object with the same field structure as the Discovery export.

Atomicwork Forms with field definitions and labels migrate as a set of Salesforce custom fields on the Case object, using the Form's field order as a loose guide for Case field sequence on the Page Layout. Conditional branching, required-field rules, and form logic are not fully exposed via the Atomicwork API, so we document the conditional logic during discovery and note it as a manual configuration step for the customer's Salesforce admin post-migration.

Atomicwork Change records (RFCs with status, priority, risk level, and CAB approvers) map to Salesforce Case using a Change Request Record Type that distinguishes them from standard support Cases. Risk level and approval chain migrate as custom fields on the Case. Linked Request references migrate as a lookup to the related Case. CAB approvers migrate as a custom multi-user field approvers__c that the customer maps to Salesforce Approvals or a manual sign-off process post-migration.

Atomicwork Knowledge Articles (title, body, category, status, tags) migrate to Salesforce Knowledge articles of the DataCategoryGroupSelection type. We map Article.body to KnowledgeArticle.Summary or a custom rich-text body field, Article.category to Salesforce Data Category, and Article.status to KnowledgeArticle.ArchiveStatus. Tag relationships from Atomicwork migrate as Salesforce Data Category assignments, and any content attachments migrate as ContentDocument records linked to the article. Salesforce Knowledge must be enabled and configured in the destination org before this phase begins.

Atomicwork Workflow automations (triggers, conditions, actions) are built in a visual builder and are not exposed via API. We do not migrate them as code. We deliver a written inventory of every active Atomicwork Workflow with its trigger type, conditions, actions, and recommended Salesforce Flow equivalent during the discovery phase. The customer's admin or a Salesforce partner uses this inventory to rebuild automations post-migration. This applies equally in both directions: existing Salesforce Flows do not migrate from the destination either.

Atomicwork Conversation records (comments on a Request from requesters, agents, and system notes) migrate to Salesforce EmailMessage records linked to the Case via the EmailMessage.ParentId reference. Each message body migrates as EmailMessage.TextBody, the author resolves to the mapped User record, and timestamps preserve as EmailMessage.MessageDate. Internal notes flagged as private in Atomicwork map to Task records on the Case rather than EmailMessage to maintain visibility controls.

Atomicwork Tags applied to Requests and Articles migrate as a custom multi-select picklist field on Case named request_tags__c. The flat tag list from Atomicwork is preserved in the import, and the customer decides whether to convert tags to Salesforce categories, topics, or retain them as a plain multi-select during scoping. Content-related tags (on Knowledge Articles) migrate as Salesforce Data Category assignments where applicable.

Atomicwork workspaces are top-level organisational containers for Requests, Assets, Users, and Workflows. Since Salesforce does not have a native workspace object, we map each Atomicwork workspace to either a Case Record Type (for simple single-org scenarios), an Experience Cloud Business Unit (for multi-tenant isolation), or a separate Salesforce org (for enterprise isolation requirements). We confirm the strategy with the customer during scoping before migration planning begins. Failing to resolve workspace mapping upfront risks importing Requests into the wrong organisational context.