Migrate from ThinkOwl to Intercom

ThinkOwl Cases map directly to Intercom Conversations. The case status (open, pending, resolved, closed) maps to Intercom's open, snoozed, and closed states. Priority from ThinkOwl (low, normal, high, urgent) maps to Intercom's priority levels and can drive SLA tier assignment. Conversation messages migrate as Conversation Parts with the original author (agent or customer) preserved. The embedded customer record resolves to the Intercom Contact/User lookup at migration time. Open cases migrate before resolved cases to minimize the delta window.

ThinkOwl Contacts embedded in Cases via embed=customer extract to standalone Intercom Contacts. We map name, email, phone, company association, and custom contact properties (the cf-prefixed fields). Email serves as the dedupe key. Phone number validation in Intercom should be disabled before migration if ThinkOwl records contain non-standard formats; we coordinate this during pre-migration setup. Custom contact properties map to Intercom custom attributes by extracting both the cf code and the display label and reconciling by label first.

ThinkOwl time entries attached to Cases record which agent logged time and for what duration. Intercom has no native time tracking object. We migrate time entries as internal notes on the parent Conversation with a structured prefix: [TIME_LOG: {agent} | {duration} | {date}]. This preserves the billable-hour context for teams that use time tracking for client billing or internal reporting. The customer decides during scoping whether time entries are migrated or omitted from scope.

ThinkOwl custom fields use cf-prefixed system codes (cf101000, cf101001, etc.) that do not appear in the API with friendly labels. We extract both the system code and the admin-displayed label during field inventory and build a mapping table. Intercom custom attributes require field type matching (text to text, number to number, date to date). Fields with mismatched types require transformation or omission. We create Intercom custom attributes in the workspace before migration begins so the attribute IDs are available for import mapping.

ThinkOwl Teams group agents and define case routing rules. We preserve team structures and map them directly to Intercom Teams. Routing rule logic (which team receives which case type) migrates as a written specification for the customer to rebuild in Intercom's assignment and routing workflow. Team-level SLA configurations migrate to Intercom SLA rules attached to the corresponding Team inbox.

ThinkOwl agent records include name, email, role, and team assignment. We map agents to Intercom Users by email lookup. Any ThinkOwl agent without a matching Intercom User goes to a reconciliation queue; the customer's admin provisions missing Intercom seats before record import resumes. Agent role (agent vs admin) maps to Intercom's admin and agent permission levels. Inactive ThinkOwl agents can be migrated as inactive Intercom users if the customer wants to preserve historical assignment.

ThinkOwl maintains a separate Drafts object for unsent replies attached to Cases. Migrating Drafts as open Conversations creates noise and potential auto-escalation in Intercom. We import draft content as internal notes on the parent Conversation with an [ORIGINAL_DRAFT] prefix, preserving the work-in-progress text for agent review without creating duplicate active conversations.

ThinkOwl stores files via its Fileee module and associates them with Cases. We export attachments and re-upload them to Intercom, re-associating by filename reference during import. File size limits and MIME-type restrictions in Intercom may require re-formatting for certain file types; we flag these during pre-migration validation. Files that exceed Intercom's size limit are omitted from import with a file inventory delivered for manual re-upload.

ThinkOwl's Business Hours API defines support operating windows used for SLA calculations. We migrate business-hours configurations as structured records and map them to Intercom SLA Rules. Intercom SLA rules support custom business hours per inbox or team, which covers the ThinkOwl business-hours use case. The destination SLA engine must be configured in Intercom's SLA settings before migration so that SLA compliance data can be validated post-import.

Tags applied to ThinkOwl Cases are exported as flat label strings. We migrate tags as-is to Intercom, mapping them to Intercom's tagging schema on the Conversation. No semantic translation is applied; tag names must match exactly. The customer specifies during scoping whether tags are included in the migration scope or omitted to reduce noise from legacy tagging taxonomies.

ThinkOwl's no-code workflow builder uses task elements (Service tasks, Call web service steps) with proprietary JSON schemas that are not exportable in portable form. We do not migrate workflows as code. During discovery we document every active workflow: trigger conditions, routing rules, escalation paths, SLA actions, and internal task assignments. We deliver a written workflow inventory and specification that maps each ThinkOwl rule to an equivalent Intercom workflow step. The customer's admin rebuilds the automations in Intercom's workflow builder post-migration.

ThinkOwl Modules define structured conversation flows with JSON-based elements, steps, and conditional logic. We export module definitions as reference documentation. Intercom Custom Objects can replicate some module data using Data Connectors, but the interactive conversation flow logic is not migratable. We deliver a module specification document so the customer or an Intercom partner can rebuild structured flows in Intercom using Custom Objects and workflow logic.