Migrate from ThinkOwl to Salesforce Service Cloud

ThinkOwl embeds customer data within Cases via the embed=customer parameter, returning a Contact record with name, email, phone, and company reference. We extract these Contact records first, map the ThinkOwl company association to a Salesforce Account, create the Account, then create the Contact with the AccountId lookup resolved. If multiple ThinkOwl Cases share the same customer email, we deduplicate into a single Salesforce Contact. Custom contact properties migrate to Salesforce custom Contact fields using the cf-prefix mapping table.

ThinkOwl companies associated with extracted Contacts map to Salesforce Account. The company name becomes Account Name, and the domain or website becomes the Account Website field used as the dedupe key. Account is created before any Contact import so the AccountId lookup is satisfied at the moment of Contact insert.

ThinkOwl Cases map directly to Salesforce Case records. The ThinkOwl Case ID is preserved in a custom field thinkowl_case_id__c for audit traceability. Case Status maps from ThinkOwl's status field (Open, In Progress, Pending, Resolved, Closed) to Salesforce Status values that the customer's admin configures during SLA setup. Priority, Origin (email, chat, voice, WhatsApp, social), and SLA breach flags transfer to equivalent Salesforce Case fields.

ThinkOwl Cases contain threaded conversations across multiple channels stored as Modules. We extract every message in the thread with its timestamp, author, channel, and direction (customer-facing or agent internal). Messages migrate as Salesforce CaseComment records for public-facing entries and InternalNote records for agent-only notes. The conversation sequence order is preserved by sorting on the original timestamp.

ThinkOwl maintains a separate Drafts object for unsent replies. Migrating Drafts as open Cases creates noise and can trigger auto-escalation rules. We import draft content as internal Case notes prefixed with [ORIGINAL_DRAFT], preserving the work-in-progress text for agent review without creating duplicate active tickets. The customer decides during scoping whether to migrate all drafts or only those created within a defined window.

ThinkOwl time entries attached to Cases record which agent logged time, duration, and optional description. Salesforce Service Cloud does not have a native time tracking standard object at all tiers, so we map time entries to a custom TimeEntry__c object with a Lookup to Case, a Lookup to User (agent), a Duration field in minutes, and a Description field. The admin configures this custom object in the destination org before migration begins.

ThinkOwl stores files via its Fileee module and associates them with Cases by filename reference. We export attachments from ThinkOwl's file storage, re-associate them by filename during import, and create Salesforce ContentDocumentLink records linking the file to the parent Case. File size limits (up to 25 MB per Salesforce file) and MIME-type restrictions are validated during export; any file exceeding the limit is flagged for the customer to handle separately.

ThinkOwl agent records include name, email, role, and team assignment. We map agent identities to Salesforce User records by email match. Any ThinkOwl agent without a corresponding Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive or archived ThinkOwl agents map to inactive Salesforce Users with the migration user flag set so historical assignments are preserved without generating notifications.

ThinkOwl teams group agents and define routing rules. We preserve team structures as Salesforce Queues (for case distribution) and map team membership to QueueMembership. Routing rule logic—which team receives which case type or priority—is documented in the written automation specification for rebuild in Salesforce Omni-Channel routing or Flow. Teams without a direct Salesforce equivalent are mapped to the closest Queue or Group based on use case.

Tags applied to ThinkOwl Cases are exported as flat label strings. We migrate tags as-is and map them to a Salesforce Case custom multi-select picklist or to the Case Tag feature if the destination org has it enabled. No semantic translation is applied; tag names are preserved verbatim and the customer chooses the tagging strategy during scoping.

ThinkOwl's Business Hours API defines support operating windows used for SLA calculations. We migrate business-hours configurations as structured records. The destination's SLA engine must be reviewed post-migration because Salesforce SLA calculations are tied to Business Hours assignment on the Case and Entitlement records. The written handoff document maps each ThinkOwl business-hours rule to its Salesforce equivalent.