Migrate from Talisma to Twenty CRM

Talisma Contact records map directly to Twenty People. Standard Talisma fields (name, email, phone, address) map to the equivalent Twenty People fields. Custom properties on Talisma Contacts require the customer to provide the Talisma field export during scoping; we create matching custom fields in Twenty's Settings > Data Model before import and map them by name at load time. Relationships to Accounts and Cases are preserved via foreign-key resolution against the target People and Company records.

Talisma Account (Organization) records map to Twenty Companies. The organization name, domain, and address fields map directly. We set the Company as the parent organization for any linked Talisma Contacts before those Contacts are imported, satisfying Twenty's relational structure requirement. If Talisma uses a hierarchical Account model (parent-subsidiary), we flatten it to the primary Company record and note the hierarchy in a custom field for the admin to re-establish in Twenty settings post-migration.

Talisma Case records map to Twenty Tasks. Case status (open, pending, resolved, closed) maps to Twenty Task status values. Case priority maps to Twenty Task priority. Case owner assignment maps to the assigned Twenty User. Multi-case threading (parent-child cases) is not a native Twenty feature; we flatten the thread to a primary Task and attach child cases as linked Tasks with a custom field case_thread_parent__c for the admin to reference. Talisma SLA timers do not migrate as timed rules; we note the original SLA breach timestamp in a custom field for the admin to configure Twenty reminders manually.

Talisma Interaction Log entries map to Twenty Activity records. Email interactions migrate as Activity entries with body text, timestamp, and direction (inbound/outbound). Phone call interactions migrate with duration and disposition notes. Chat interactions migrate as Activity entries with the transcript text preserved in the notes field. We set the Activity's target to the resolved Twenty Person or Company record. Activity type taxonomy from Talisma (email, phone, chat, cobrowse) is preserved in a custom field activity_channel__c for filtering and reporting in Twenty.

Talisma Chat and Cobrowse sessions are stored in a separate module from the standard Interaction Log. We extract session metadata (session start/end time, agent, customer, channel type) and transcript text where accessible from the Talisma export. Since Twenty has no native chat session object, session metadata and transcripts land as structured Notes attached to the relevant Person record, with a custom field session_type__c (Chat or Cobrowse) for categorization. This approach preserves the history for search and audit without requiring a custom object.

Talisma custom field definitions are stored in the application configuration and require a Talisma administrator to export the full field list during discovery. We cannot enumerate the Talisma schema from outside the platform. Upon receiving the field export, we create matching custom fields in Twenty's Settings > Data Model with appropriate types (text, number, date, picklist, checkbox). We flag any Talisma field type that has no direct Twenty equivalent (such as Talisma-specific lookup types) and present options during scoping. Custom fields not submitted during discovery appear unmapped and may be dropped at load time.

Talisma user records map to Twenty Users. We extract the user list with role and team assignments from Talisma. Talisma roles (agent, supervisor, admin) do not map 1:1 to Twenty's role model, so we apply a default role mapping during migration (admin to Admin, agent to Standard User) and flag any role that requires a different mapping for the admin to review in Twenty Settings post-migration. Inactive Talisma users are migrated as inactive Twenty Users to preserve historical assignment on Cases and Interaction Logs.

Talisma Product records with SKU, name, description, and pricing fields map to Twenty Products. We create Product entries during migration and link them to Opportunities (Twenty's deal equivalent) where applicable. Talisma bundling logic and pricing-rule conditions do not have a native Twenty equivalent and are documented in the migration inventory for the admin to reconfigure in Twenty's product settings post-migration.

Talisma binary attachments linked to Contacts, Cases, or Accounts export as files. We preserve the original filename, association, and binary content during extraction. For Twenty import, we use Twenty's API attachment endpoint to re-associate each file with the target Person, Company, or Task record. Note that Twenty's CSV import path does not include file attachments per the platform's current documentation; we handle attachments via API in a separate post-CSV phase. Customers with thousands of attachments should plan additional validation time in the cutover window to confirm re-association accuracy.

Talisma KnowledgeBase is an enterprise wiki product separate from the CRM data layer. KnowledgeBase articles are not accessible as records through Talisma's export tooling in the same pass as CRM entities. We do not include KnowledgeBase in the standard migration scope. If the customer requires KnowledgeBase migration, we treat it as a separate engagement with its own scoping and pricing. The customer should plan to rebuild or re-import KnowledgeBase content manually or via a dedicated wiki migration tool.

Talisma workflows (triggers, escalations, auto-assignment rules, SLA timers) are stored in the application configuration layer and are not exportable as data records. We document every Talisma workflow identified in the configuration export and deliver a written workflow inventory that maps each rule's trigger, conditions, and actions to a recommended Twenty equivalent (such as a reminder, assignment rule, or task automation in Twenty Settings). The customer's admin rebuilds these in Twenty post-migration. We do not migrate workflows as code or provide post-migration admin support for workflow rebuild as standard scope.