Migrate from Capacity to Salesforce Service Cloud

Capacity Tickets map directly to Salesforce Cases. The Capacity ticket status (Open, Pending, Resolved, Closed) maps to Salesforce Case Status with value translation; the mapping table is defined during discovery because Capacity status values vary by workspace configuration. Priority maps to Case Priority. Custom fields on Capacity tickets are mapped to Salesforce custom fields by type: text to Text(255), number to Number, date to Date, picklist to Picklist with value translation. We pre-create all custom fields in the destination org before migration begins.

Each Capacity Ticket contains a Conversation thread with message records, timestamps, author attribution, and internal notes. We split these into Salesforce EmailMessage records (visible customer-facing thread) and Task records (internal notes flagged as private in Capacity). The EmailMessage is linked to the Case via ParentId; internal notes become Task records with Subject and Description populated from Capacity's message body. Attachments on individual messages are linked as ContentDocumentLink records after the parent Case is inserted.

Capacity KB articles map to Salesforce Knowledge Articles. Title, Body (plain text export), Summary, and URL Name migrate. Capacity article metadata (author, creation date, last modified) populates Salesforce Knowledge article fields. We note that Capacity's KB export includes article text and category assignments but does not preserve rich formatting, embedded media, or version history; we extract available content and flag formatting losses that require post-migration review.

Capacity KB category hierarchies map to Salesforce Knowledge Data Category Groups and individual Data Categories. We extract the full category tree from Capacity and create equivalent Data Category structures in Salesforce Knowledge. Nested hierarchies require flattening or cascading Data Category assignments depending on the destination org's Knowledge configuration. The category mapping is validated in a sandbox migration before production.

Capacity Users (agents, admins) map to Salesforce Users by email match. We extract the full user roster including name, email, role, and team assignment. Roles map to Salesforce Permission Sets or Profile assignments; team assignments map to Salesforce Queues for routing. The customer's Salesforce admin provisions Users in the destination org before migration, and we validate the email match against the Salesforce User table to catch any missing accounts before record import begins.

Capacity Teams (agent groupings for routing) map to Salesforce Queues. Queue members are populated from Capacity team member assignments. Routing rules that reference Capacity teams are flagged during discovery and documented for recreation as Salesforce Omni-Channel Routing Configurations or Flow-based assignment rules at the destination.

File attachments on Capacity tickets and KB articles migrate as Salesforce ContentDocument records linked via ContentDocumentLink to the parent Case or Knowledge Article. Large file handling requires size validation against Salesforce's 25 MB per file limit for attachments; files exceeding this threshold are flagged for manual handling or chunked upload via the Salesforce Content API.

Tags applied to Capacity tickets for categorization are extracted as metadata. We map these to Salesforce Tags on Case records where the destination org has Tags enabled, or to a custom multi-select picklist field tag__c if Tags are not available in the customer's Service Cloud edition. The customer chooses the tagging strategy during scoping based on their edition and usage pattern.

Custom fields on Capacity tickets require field-level mapping to Salesforce custom fields. We validate custom field data types during discovery (text length, numeric precision, picklist values) and create equivalent Salesforce custom fields with matching API names before migration. Picklist values that exist in Capacity but not in Salesforce are flagged for value translation; some may require a custom picklist value set to be created in the destination org before import.

Capacity automation rules, routing logic, and workflow triggers are not accessible via the Capacity API. We document the current automation configuration during discovery: trigger conditions, action types, delay rules, and routing assignments. This documentation is delivered as a written inventory with recommended Salesforce Flow equivalents for each Capacity automation. The customer's admin or a Salesforce partner rebuilds these post-migration.

Connected integrations with Slack, Microsoft Teams, and other third-party services are configured at the Capacity platform level and cannot be migrated. We document the list of active integrations during discovery so customers can reconfigure them at the destination. For Slack and Teams, Salesforce offers native Slack integration and Microsoft Teams integration through the Salesforce AppExchange that can be reconfigured post-migration.