Migrate from ThinkOwl to Zendesk

ThinkOwl Cases map directly to Zendesk Tickets as the primary support object. The case subject becomes Ticket subject, the embedded customer (via embed=customer) resolves to the Zendesk Requester User record, and status values (Open, In Progress, Resolved, Closed) map to Zendesk ticket Status values. Conversation history migrates as Ticket Comments ordered by timestamp. We preserve the original ThinkOwl Case ID in a custom field thinkowl_case_id__c for cross-reference during the warranty period.

ThinkOwl Contact records (email, name, phone, company association, custom contact properties) map to Zendesk End User records. The Contact's primary email is the dedupe key; duplicate contacts with matching emails merge during import. Custom contact properties from ThinkOwl migrate as Zendesk user custom fields. Organization assignment from ThinkOwl's company association resolves to the Zendesk Organization lookup.

ThinkOwl Company records map to Zendesk Organizations. Company name becomes Organization name, and company domain is mapped to Organization domain for automatic user-organization matching in Zendesk. If no matching Organization exists when a Contact imports, we create the Organization first to satisfy the lookup constraint.

ThinkOwl cf-prefixed field codes (cf101000, cf101001, etc.) are mapped to typed Zendesk custom fields. We extract both the admin-display label and the system code during field inventory and create a mapping table that matches Zendesk field names to ThinkOwl labels. Field types are inferred from ThinkOwl's data: date fields become date pickers, dropdowns become tagger fields with the same options, and text fields become text fields. Zendesk's Legacy Custom Objects (retiring July 2026) are avoided; any ThinkOwl custom objects are migrated as Zendesk custom fields on Ticket or User unless they require relational data, in which case we document the schema for rebuilding in Zendesk's new Custom Objects framework.

ThinkOwl Time Entries are child objects of Cases, recording agent name, duration, and optional description. Zendesk has no native time-entry child object; we migrate time entries as a combination of a custom multi-line text field (ticket_time_entries__c) with comma-separated entries (agent, duration, timestamp, note) and as an internal Note on the ticket with a [TIME_ENTRY] prefix. The customer chooses the preferred representation during scoping.

ThinkOwl Drafts are a separate object for unsent agent replies. Migrating Drafts as open Tickets creates noise and potential auto-escalation in Zendesk. We import draft content as internal Ticket Notes with an [ORIGINAL_DRAFT] prefix, preserving the work-in-progress text for agent review without creating duplicate active tickets. The original draft timestamp is preserved in the note body.

ThinkOwl files stored in Fileee are exported and re-associated by filename reference during import. ThinkOwl attachments over 20MB require chunked upload via Zendesk's multipart endpoint. Zendesk's 1MB attachment limit for API uploads is respected; files exceeding this threshold are flagged for manual upload post-migration with a reference list provided.

ThinkOwl Teams group agents and define routing rules. We preserve team structures as Zendesk Groups with matching names. Routing rule logic (which team receives which case type) migrates as a written routing matrix, not as Zendesk automations, because ThinkOwl's routing rules use conditional branching not directly translatable to Zendesk trigger conditions.

ThinkOwl Agent records (name, email, role, team assignment) map to Zendesk User records with the agent role. We resolve agents by email match against the Zendesk User table. Agents without a matching Zendesk User go to a reconciliation queue for the customer's admin to provision before record import resumes, since OwnerId is a required field on Tickets in most Zendesk configurations.

ThinkOwl tags applied to Cases export as flat label strings. We migrate tags as-is to Zendesk Tags. No semantic translation is applied; tag names must match exactly between systems for the Zendesk tag index to function correctly. Tags that exist in ThinkOwl but not yet in Zendesk are created during import.

ThinkOwl Business Hours configurations (support operating windows used for SLA calculations) migrate to Zendesk Business Hours as structured records. The Zendesk SLA engine references Business Hours for first reply time and next response time calculations. We map the time windows directly; timezone is preserved from the ThinkOwl configuration.

ThinkOwl's no-code workflow builder uses proprietary JSON task-element schemas (Service tasks, Call web service steps, conditional branches) with no documented export endpoint. We do not migrate Business Process definitions as code. During discovery we document the current workflow logic—routing rules, escalation paths, SLA triggers, conditional branches—and deliver a written specification with recommended Zendesk Trigger and Macro equivalents so the customer's admin can rebuild them in Zendesk. ThinkOwl Modules (structured conversation flows in Conversations) are exported as JSON for reference but not imported as Zendesk objects because the conversation flow schema has no Zendesk equivalent.