Migrate from Twenty CRM to Salesforce Sales Cloud

Twenty Companies map directly to Salesforce Account. The company domain field becomes the Account Website field and serves as the dedupe key during import. We use the domain as an external ID on Account to prevent duplicate creates when matching records exist in Salesforce. Account must be the first object imported because both People (via companyId) and Opportunities (via companyId) reference it through foreign key lookups.

Twenty People map to Salesforce Contact. The email field serves as the unique dedupe key and external ID. We resolve the companyId foreign key to a Salesforce AccountId at migration time by querying the Account external ID mapping created during the Account phase. Contacts are inserted with AccountId populated for every record where a matching Account exists; contacts without a resolved Account are held in a reconciliation queue for the customer admin to resolve before continuing.

Twenty Opportunities map to Salesforce Opportunity. We resolve both companyId (to AccountId) and the personId relations (to PrimaryContactId via OpportunityContactRole) at migration time. Stage names from Twenty map to Salesforce StageName values that we configure as a Sales Process before migration begins. Amount, closeDate, and probability percentage transfer directly to Opportunity fields.

Twenty Tasks map to Salesforce Task. We resolve the relational target (linked to People, Companies, or Opportunities) to a Salesforce WhatId or WhoId at migration time by querying the ID mapping tables created during the Company, People, and Opportunity phases. Status, Priority, ActivityDate, and description migrate directly. Tasks without a resolvable parent record are imported with no WhatId and flagged for manual reassignment.

Twenty Notes map to Salesforce Note records. We resolve the relational target to a Salesforce record ID (Contact, Account, or Opportunity) and link via ContentDocumentLink. Note body content migrates as rich text. Attachments within notes migrate as ContentDocument records linked to the parent via ContentDocumentLink. Notes without a resolvable parent are flagged for manual reassignment during reconciliation.

Twenty Custom Objects (user-defined entities on Organization or Pro tier) map to Salesforce custom objects of equivalent API name. We pre-create the destination schema in Salesforce including all custom fields, field types, and lookup relationships before any data import. Custom object records are migrated last because they frequently reference People, Companies, or Opportunities through foreign keys that must resolve to Salesforce record IDs.

Twenty's People.companyId foreign key maps to Salesforce Contact.AccountId via an explicit lookup resolution step. We extract all unique companyId values from the People export, map each to its corresponding Salesforce Account ID using the external ID mapping, and attach that AccountId to each Contact record at insert time. This lookup resolution is the critical step that prevents Contact records from being orphaned from their Account.

Twenty Opportunities that reference a companyId are resolved to Salesforce AccountId using the same Account mapping table created during the Account phase. Every Opportunity must have a valid AccountId or ContactId before Salesforce accepts the insert, so this lookup resolution happens before the Opportunity phase begins.

Twenty Opportunities that link to People records generate Salesforce OpportunityContactRole records during migration. The personId maps to the Salesforce Contact ID resolved during the People phase, and the OpportunityContactRole is created with Role=Primary Contact. Multiple personId links on a single Twenty Opportunity produce multiple OpportunityContactRole records in Salesforce.

Twenty Tasks can be linked to any record type (People, Company, Opportunity). We extract the relation target type and ID from Twenty, resolve the target ID to the corresponding Salesforce record ID using the ID mapping tables, and write the resolved ID to Task.WhatId. Tasks linked to People resolve to WhoId; tasks linked to Company or Opportunity resolve to WhatId.

Twenty users referenced as record owners (on People, Companies, Opportunities, Tasks) are mapped to Salesforce User records by email match. Any Twenty owner without a matching Salesforce User is placed in a reconciliation queue. The customer's Salesforce admin provisions missing users before the migration continues because OwnerId is required on Opportunity and Task records.

Twenty's uniqueness check runs against all records including soft-deleted ones visible in the deleted view. If a Company with domain example.com exists in the deleted view and we import a new Company with the same domain, Twenty restores the deleted record instead of creating a new one. We detect this condition during scoping and coordinate with the customer to either purge deleted records before migration or map to the existing restored record in Salesforce.

Twenty People with the same email as a soft-deleted record trigger the restore behavior rather than a create. We pre-query Twenty's deleted-view for People and Companies before migration begins and flag conflicts. The customer chooses to either permanently delete the soft-deleted records or accept that the restored record will be the destination target. This decision is made before any data is written.