Migrate from Talisma to Pipedrive

Talisma Contact records map directly to Pipedrive Person. Standard fields (name, email, phone, address) map 1:1 to Pipedrive Person fields. Custom properties on Talisma Contacts are enumerated from the Talisma configuration export and mapped to Pipedrive custom Person fields of the matching type (string, number, date, single-select, multi-select). The Talisma-Contact-to-Case and Talisma-Contact-to-Account relationships are resolved as Lookups at migration time by resolving the Talisma foreign-key IDs to Pipedrive Person IDs and Organization IDs respectively.

Talisma Organization records map to Pipedrive Organization. Organization name, domain, address, industry, and employee count map to their Pipedrive equivalents. The Talisma Account-Contact hierarchy (parent-child Account relationships) maps to Pipedrive Organization hierarchy if the Talisma deployment uses it; otherwise all Organizations are imported as top-level. We flag any Talisma Organization that has no linked Contacts as a standalone record requiring customer review.

Talisma Cases do not map 1:1 to a single Pipedrive object. We offer two strategies: (1) Map Talisma Cases to Pipedrive Deals if the customer's Talisma Cases track sales opportunities — Case status maps to Deal stage, Case priority to Deal priority, and the Talisma Case owner becomes the Deal owner. (2) Map to Pipedrive Cases (Service Cloud add-on) if the customer uses Talisma for support-case management — Case status maps to Case status, Case type becomes a Case custom field, and parent-child Case threading is flattened into linked notes. The customer selects the strategy during scoping. Multi-case threading (parent Case with linked child Cases) is preserved as a structured note on the primary Deal or Case.

Talisma Interaction Log records map to Pipedrive Activity records. Email interactions map to Pipedrive Activity type=email with the email content stored as an Activity note and a content hash preserved for deduplication. Phone call interactions map to Pipedrive Activity type=call with duration and disposition stored in custom fields. Chat interactions from the Interaction Log (not the separate Chat module) map to Pipedrive Activity type=note with the chat transcript stored as the note body. We preserve the Talisma interaction timestamp on each Activity and resolve the linked Person and Organization IDs at migration time.

Talisma Chat & Cobrowse sessions are stored in a module separate from the Interaction Log. We extract session metadata (start time, end time, agent, channel) and transcript text where accessible via the Talisma export. Pipedrive has no native cobrowse or chat-transcript object, so chat and cobrowse data lands as a Pipedrive Activity of type=note with a custom activity type field distinguishing chat from cobrowse. Event flags (screen share started, consent granted) are stored as custom fields on the note. This mapping requires customer sign-off during scoping because the transcript volume can affect migration timeline.

Talisma User records (agents, supervisors, admins) map to Pipedrive Users by email address match. Talisma role assignments (agent, supervisor, admin) do not map 1:1 to Pipedrive's permission model, which uses Admin, Member, and Restricted User roles plus pipeline-level visibility settings. We apply a default role mapping (Talisma admin -> Pipedrive Admin, Talisma supervisor -> Pipedrive Member with full visibility, Talisma agent -> Pipedrive Member) and flag any Talisma role that cannot be represented in Pipedrive for the customer's admin to resolve before production migration.

Talisma Product catalog records with SKU, pricing, and description map to Pipedrive Products. Product pricing tiers from Talisma map to Pipedrive Product pricing with the price-per-unit preserved. Bundle and pricing-rule logic from Talisma is flagged as a manual-rebuild item because Pipedrive Products do not support complex pricing rules natively without an external CPQ integration.

Talisma binary attachments linked to Contacts, Cases, or Accounts export with their original filename and MIME type. We preserve the attachment-to-record association during migration and load each file as a Pipedrive Activity attachment linked to the corresponding Person, Organization, or Deal. Talisma deployments that store attachments in a proprietary or database-blob format are flagged during discovery because re-encoding may be required before load into Pipedrive's file store.

Talisma custom field definitions exist only in the application configuration, not as queryable API records. We request the full Talisma field list from the customer during discovery and map each custom field to a Pipedrive custom field of the matching type. Talisma multi-select fields map to Pipedrive multi-select, Talisma date fields map to Pipedrive date fields, and Talisma numeric fields map to Pipedrive numeric fields. Any Talisma custom field not submitted during scoping appears unmapped and is excluded from the load. The customer reviews all unmapped fields before production migration begins.

Talisma workflows (triggers, escalations, auto-assignment rules, SLA timers) are application-layer configurations, not data records, and cannot be exported as migration data. We document every Talisma workflow identified from the configuration export and deliver a written inventory with the workflow name, trigger type, conditions, actions, and a recommended Pipedrive Workflow equivalent. The customer's admin rebuilds workflows in Pipedrive's Workflows and Activity Automation sections post-migration.

Talisma KnowledgeBase records are content objects in a separate module and do not map to Pipedrive's data model, which has no native knowledge-base feature. We export KnowledgeBase content as structured documents (HTML or Markdown) during the Talisma extraction and deliver them for the customer to import into a third-party knowledge-base tool (Notion, Confluence, or a dedicated knowledge-base product) or to create as Pipedrive Notes or custom Activity notes. This is a manual-setup item not included in standard migration scope unless explicitly contracted.