Migrate from Drag to Salesforce Service Cloud

Drag conversations are Gmail threads surfaced through the Drag layer. We extract the full thread history including all replies, timestamps, sender, recipient, subject, and body, and import as Salesforce Case records. The thread subject becomes the Case Subject; the most recent body becomes Description. Thread-level message IDs are preserved in a custom field drag_thread_id__c for audit. Closed conversations map to Case.Status of Closed (with appropriate sub-status per the customer's case lifecycle). Open conversations map to New or In Progress based on the last agent activity timestamp.

Drag pipeline stages (e.g., To-Do, In Progress, Waiting, Done) map to Salesforce Case Status values. We export the stage names and column order from the CSV, then configure a Case Record Type with a corresponding Case Status picklist that matches the original sequence. Stage probability is not applicable at Case level since Cases do not track win/loss probability the way Opportunities do.

Drag Kanban boards represent separate workflow contexts. Multiple boards in Drag map to Salesforce Case Record Types, each with its own Page Layout and Case Status values. The customer selects which board becomes the default Record Type during scoping. Customers with only one board use the default Service Cloud Case Record Type without additional configuration.

Drag agents are team members assigned to conversations. We extract agent email address and display name from the CSV export and match by email against the Salesforce destination org's User table. Any Agent without a matching Salesforce User is held in a reconciliation queue; the customer's admin provisions the missing Users before record import resumes.

Drag does not maintain a standalone contact database. We derive Contact records from unique senders and recipients across all email threads: name and email address are extracted from thread participant headers, deduplicated, and imported as Salesforce Contacts. Each Contact is linked to an Account using domain-based matching (extracting the domain from the email address) or, where possible, matching against any existing Accounts in the destination org. For customers with existing Salesforce Accounts, the customer provides a domain-to-Account mapping during scoping.

Drag tags are flat labels applied to conversations for categorization. We export all unique tag values and migrate them as Salesforce Tags (the standard tag feature for records). Alternatively, if the customer has a defined taxonomy of tag categories, we migrate as a custom multi-select picklist on Case for more structured reporting. The customer selects the strategy during scoping.

Files attached to email threads are downloaded during the export phase and re-attached in Salesforce as ContentDocument records linked to the parent Case via ContentDocumentLink. Large attachments exceeding Salesforce file size limits (25 MB per file) require separate storage handling or a pre-migration decision on archiving. Attachment metadata (original filename, size, MIME type) is preserved in custom Case fields for audit.

Drag Teams group agents for routing purposes. We export team membership (agent-to-team assignments) and map to Salesforce Queues for Case assignment routing or Groups for collaboration. The destination queue type depends on whether the customer uses Omni-Channel for skills-based routing (Queues required) or simple group-based assignment (Groups sufficient).

Drag canned responses (Professional and Enterprise tiers) are shared reply templates with shortcut triggers. We export template body text and shortcut keywords. Formatting and conditional logic from Drag do not carry over; post-migration, the customer's admin recreates them as Salesforce Lightning Email Templates with merge fields targeting the Case and Contact objects. This is a manual step outside the data migration scope.

Drag's free and lower paid tiers do not expose a custom fields API, and even Enterprise exposes it inconsistently. Any per-conversation structured data beyond assignee, stage, and tags is not programmatically accessible for import. We flag any fields identified in the UI export as not migratable and document them in the migration handoff so the customer's admin can recreate them as Salesforce custom fields on Case post-migration.