Migrate from CRM and Deals for Zendesk to Twenty CRM

Zendesk Contacts map 1:1 to Twenty Persons. Standard fields (name, email, phone, address, custom fields) migrate directly. We use email as the dedupe key during import. If a Zendesk Contact is linked to an Organization, we resolve the Organization-to-Company reference before inserting the Person record so that the relationship is satisfied at write time. Role and title fields map from Zendesk's contact_attributes to Twenty's Person position and social URLs.

Zendesk Organizations map directly to Twenty Companies. The organization domain_name becomes the Company domain field. Industry, annual_revenue, and number_of_employees from Zendesk custom fields map to Twenty's Company custom fields. Companies are inserted before Persons so that the Company-Person relationship is satisfied at the moment of Person import. Note that Zendesk's Organizations are flat; if the source uses nested org structures, we flatten them into Twenty's single-tier Company model.

Zendesk Deals map to Twenty Opportunities. The key complexity is that Zendesk stores pipeline_id and stage_id as separate lookup fields, while Twenty collapses pipeline and stage into a single Opportunity record with a stage_name and probability. We extract the deal's pipeline stage name and probability from Zendesk's Pipelines API, resolve the pipeline assignment, and write both as Opportunity properties. Any custom fields on the Zendesk Deal (discount_rate, close_date_reason, loss_reason) map to Twenty custom Opportunity fields.

Zendesk Pipeline Stages have ordering, names, and probabilities that map to Twenty Opportunity Stage values. We extract the full stage list from Zendesk's Pipelines API, create the corresponding stage values in Twenty's opportunity stage configuration, and preserve probability percentages. Stage names that exceed Twenty's character limit are truncated. If the source uses multiple Zendesk pipelines, each maps to a separate Twenty Opportunity with stage names scoped per Opportunity record.

Zendesk does not expose stage-change history as a first-class Deal field. Stage transitions are logged as Activities with type = 'deal_stage_changed'. We run a de-normalization query joining Activities to Deals where activity_type = 'deal_stage_changed', extract the from_stage and to_stage values, and construct a synthetic stage-history array ordered by timestamp. This array is written as a custom field (stage_history_json) on the Twenty Opportunity or as a series of Note records on the Opportunity timeline. The customer chooses the preferred representation during scoping.

Zendesk Activities (calls, emails, meetings, notes) attached to Contacts and Deals migrate as Timeline Events in Twenty. We resolve the Zendesk contact_id or deal_id to the corresponding Twenty Person or Opportunity record and write the activity as a dated event. Call duration, disposition, and recording URL from Zendesk call engagements migrate as custom fields on the Twenty timeline event. Note that threaded conversation views and rich text email bodies migrate as plain text; the threaded layout does not reconstruct in Twenty's flat timeline.

Zendesk Tickets have no direct equivalent in Twenty CRM, which is a sales-focused platform without a native ticket object. We map tickets to Note records attached to the corresponding Person or Company, preserving status, priority, assignee, tags, and conversation body. The ticket's requester maps to the Person; the assignee maps to the Twenty workspace user. Status and priority values are preserved as custom fields on the Note so the customer's admin can filter by ticket state. If the customer needs a ticketing system post-migration, we recommend a dedicated help desk integration (Zendesk Support, Intercom, or Freshdesk) rather than rebuilding tickets in Twenty.

Zendesk v2 Custom Objects map to Twenty custom objects. We first confirm that Legacy Custom Objects have been migrated to v2 (the Legacy API is read-only as of January 15, 2026). We then create the target schema in Twenty, including all custom fields, relationship fields, and validation rules, before importing any data. Relationship fields that point to Contacts or Organizations resolve via the Person and Company lookups established in earlier migration phases. Plan-tier limits on Zendesk (3 on Team, 5 on Growth, 30 on Professional, 50 on Enterprise Plus) do not apply in Twenty, which has no per-plan object count ceiling.

Zendesk Users and Agents map to Twenty workspace members by email match. We extract every distinct owner_id referenced on Contact, Organization, Deal, and Activity record, match by email against the Twenty workspace user table, and flag any owner without a matching user for admin provisioning. Active versus inactive status migrates from Zendesk's user role (agent, admin). Role-based permissions (Zendesk groups, role types) do not map directly; the customer's admin assigns Twenty workspace roles post-migration.

Zendesk tags on contacts, organizations, and deals are flat string arrays. Twenty does not have a native tag object, so we map tags to a custom text field on the relevant record (Person, Company, or Opportunity). The customer chooses whether tags concatenate as a comma-separated string or populate a multi-select custom field if Twenty's schema supports it. Tag-based automations in Zendesk do not migrate; we note them in the automation inventory for rebuild.

Inline images and file attachments on Zendesk tickets, contacts, and articles must be fetched separately from Zendesk's attachments API endpoint. We download all attachments, re-upload to Twenty's storage layer, and link them to the parent record. If Twenty's attachment API does not support inline image positioning, attachments are linked as separate file records on the Person or Company with a reference note indicating the original context. Attachment migration runs after all primary record types are written to avoid blocking the main migration path.