Migrate from Talisma to Salesforce Sales Cloud

Talisma Contact records map directly to Salesforce Contact when the contact is associated with an Account. Contacts that represent unqualified prospects without an organizational affiliation map to Salesforce Lead. We resolve the Contact versus Lead assignment during scoping based on the customer's Talisma configuration — specifically whether the contact has an Account association and what lifecycle or status property Talisma uses for qualification. The original Talisma contact ID is preserved in a custom field talisma_contact_id__c for audit reconciliation.

Talisma Organization records map 1:1 to Salesforce Account. The Account Name maps from the Talisma Organization name field, and the website maps from the organization domain if present. We use the Account record as the parent anchor before importing any Contact records, resolving the Talisma Organization-to-Account lookup at import time. Parent-child organization hierarchies in Talisma map to Salesforce Account Hierarchies if the customer uses that feature.

Talisma Case records map to Salesforce Case when the destination org includes Service Cloud. Case status, priority, owner assignment, and timestamps migrate directly. Talisma's case-type routing (used in higher education for application status, financial aid, and enrollment case categories) maps to Salesforce Case Record Type. Parent-child case threading in Talisma maps to the Salesforce Case parent-case relationship. We flag any Talisma SLA timer field that cannot map to a Salesforce Entitlement or Omni-Channel routing field for admin review.

Talisma Interaction Logs are the unified record of email, phone, and chat events against a Contact. We split these by interaction type: email interactions map to Salesforce Task with Subject, Description, and ActivityDate preserved; phone call interactions map to Task with TaskSubtype = Call and CallDurationInSeconds in a custom field; meeting interactions map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. The Talisma interaction timestamp becomes ActivityDate on the Task or StartDateTime on the Event, preserving timeline ordering.

Talisma Chat and Cobrowse sessions are stored in a separate module from the standard Interaction Log. Session metadata (session start, end, duration, Cobrowse event flags) exports from Talisma as a distinct query. We map this data to Salesforce Notes linked via ContentDocumentLink to the parent Contact or Case, with session type and Cobrowse event data stored in custom fields. Cobrowse event flags that require structured retention (e.g., compliance logging for banking or government) are mapped to a custom object cobrowse_session__c if the customer's Salesforce edition supports it.

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 externally. Custom fields on Contacts, Cases, and Organizations map to Salesforce custom fields of the matching type (text, number, picklist, date, checkbox) created in the destination org before migration. Fields with no Salesforce equivalent are flagged for a custom field or note fall-back decision during scoping. Any Talisma custom field not submitted in the discovery field list is dropped at load time.

Talisma User records export with role and team assignments. Talisma roles (agent, supervisor, administrator) do not map 1:1 to every destination Salesforce org's permission model, so we apply a default role mapping (agent to Standard User, supervisor to Sales Manager profile, administrator to System Administrator) and flag any Talisma role without a direct Salesforce equivalent for the customer's admin to resolve. We resolve Talisma user assignments on Cases and Interaction Logs by matching the Talisma user email to the Salesforce User table.

Talisma binary attachments linked to Contacts, Cases, or Accounts export as file blobs. We preserve the original filename and the ContentDocumentLink relationship to the parent record. Some Talisma deployments store attachments in a proprietary format that requires re-encoding during extraction; we test file restoration for every attachment in staging and flag any file that cannot be decoded. Attachments exceeding Salesforce's 25 MB per-file limit are flagged for the customer's admin to store externally with a ContentDocument link pointing to the external URL.

Talisma Product records with SKU, pricing, and description fields map to Salesforce Product2. We create Standard Price Book entries for each Product2 during migration. Talisma pricing-rule logic (volume discounts, tiered pricing) does not transfer as configuration; we document the pricing rules identified in the Talisma configuration export and recommend Salesforce CPQ as the replacement for complex quoting workflows.

Talisma workflows — triggers, escalations, auto-assignment rules, and SLA timers — are application-layer configurations stored in the Talisma application database, not as data records. They are not exportable as executable code. We document every workflow identified in the Talisma configuration export (including trigger conditions, action types, and assignment logic) in a written Workflow Inventory deliverable. The customer's Salesforce admin rebuilds these as Salesforce Flow, Process Builder, or Assignment Rules post-migration. SLA timers that mapped to Talisma Case escalations do not have a direct Salesforce equivalent without Service Cloud Entitlements, which we flag during scoping.

Talisma KnowledgeBase product (enterprise wiki and self-service knowledge management) does not map to a standard Salesforce object without Knowledge Base enabled in the destination org. If the customer has Talisma KnowledgeBase articles and enables Salesforce Knowledge during migration, we map article title, body content, category, and publish status to KnowledgeArticleVersion. If Salesforce Knowledge is not in scope, we document the article count and content structure for the customer's admin to rebuild in Salesforce or a third-party knowledge tool.

Talisma's CXM.AI product line (AI-powered agent assist and real-time analytics) launched in early 2025 as a cloud, on-premise, or hybrid module. If the customer uses CXM.AI scoring, AI-generated interaction summaries, or predictive routing data stored in Talisma, these do not map to standard Salesforce Einstein fields without explicit AI feature enablement. We flag any CXM.AI data field identified during extraction as a custom field or a documented handoff for Salesforce Einstein GPT or Revenue Intelligence configuration post-migration.