Migrate from Talisma to Odoo CRM

Talisma Contact records map to Odoo Contact (res.partner) with the contact address type. The Talisma Contact's relationship to Account (organization) becomes the parent_id link to the mapped Company. Standard Talisma fields (name, email, phone, title) map directly. Custom Talisma properties on Contact require the Talisma field list from the customer during discovery; without it, unmapped custom properties are flagged and may be dropped at load time.

Talisma Organization records map to Odoo Company (res.partner with type=company). The Account-Contact hierarchy from Talisma translates directly — Talisma Contacts with a parent Account become Odoo Contacts with a parent_id pointing to the mapped Company. Company-level custom fields from Talisma map to custom res.partner fields scoped to the company type.

Talisma Cases map to Odoo CRM Leads or Opportunities depending on case type. Cases with status Open or Pending map to Odoo Lead. Cases with an associated revenue value and a clear sales pipeline intent map to Opportunity. Parent-child case threading from Talisma becomes a custom parent_case_id field on the child Odoo Lead or Opportunity. SLA timers from Talisma Cases cannot migrate as live timers; they are stored as custom fields with the original SLA target timestamp for Odoo admin review.

Talisma interaction logs (email, phone, chat transcript text) map to Odoo Mail Message records linked to the parent Contact or Company via res_id and model. Interaction type (email, phone, chat) is preserved in a custom field interaction_type__c. Call duration and disposition map to custom fields since Odoo CRM does not have a native call disposition taxonomy.

Talisma Chat and Cobrowse sessions are stored in a separate module from standard interaction logs. We extract session metadata (session start, end, duration, cobrowse URL flags) and transcript text as a structured Note attached to the parent Contact. Cobrowse event markers (screen-share start/stop) become custom fields on the Note; the full cobrowse recording cannot be migrated as binary data and is documented as a session reference for the customer's admin to follow up on.

Talisma Product records with SKU, pricing, and description map to Odoo product.template. Product pricing tiers from Talisma's catalog map to Odoo pricelist entries on the default pricelist. Bundle and pricing-rule logic from Talisma's advanced catalog setup does not migrate automatically; we document the pricing rule structure for the customer's admin to reconfigure in Odoo Pricelists.

Talisma custom field definitions on Contacts, Accounts, Cases, and Products are stored in the Talisma application configuration and require a Talisma admin to export the full field list during discovery. We cannot enumerate the schema from the outside. Once the field list is provided, we create matching custom fields in Odoo (res.partner, crm.lead, sale.order) via Odoo Studio or direct field creation, matching the Talisma field type to the closest Odoo field type (text to char, number to float or integer, date to date).

Talisma User records (agent, supervisor, admin roles) map to Odoo res.users. We extract the full user list with role assignments and map Talisma roles to Odoo security groups: Talisma agent maps to Odoo internal user, supervisor maps to Odoo user with team manager group, admin maps to Odoo super-user or custom admin group. We flag any Talisma role that does not map cleanly to an Odoo security group for the customer's admin to assign during staging.

Talisma binary attachments linked to Contacts, Cases, or Accounts export as file blobs and map to Odoo ir.attachment records. We preserve the original filename, MIME type, and the res_model/res_id linking to the parent Contact, Company, or Lead. Some Talisma deployments store attachments in a proprietary format; we test re-encoding during staging and flag any file that cannot be restored to its original format. Large attachment volumes (over 5,000 files) extend the cutover validation window.

Talisma workflows (triggers, escalations, auto-assignment rules, SLA timers) are application-layer configurations, not data records. They do not export as records and cannot be loaded into Odoo CRM via API. We document every Talisma workflow identified in the configuration export as a written inventory with trigger, conditions, and actions described in plain language. The customer's admin rebuilds these in Odoo Studio Automated Actions or through an Odoo integration partner post-migration.

Talisma KnowledgeBase articles map to Odoo Documents (if the Documents app is installed) or to structured Notes on the relevant Contact or Company. Article categories map to Odoo folder structures or tags. We preserve article content, last-modified date, and author attribution. If the customer uses Odoo Knowledge app, articles map to knowledge.article records with folder hierarchy preserved.

Talisma Campaign Response records (responses to enrollment, marketing, or outreach campaigns) map to Odoo Lead tags with a prefix such as talisma_campaign__. Alternatively, if the customer uses Odoo Marketing Automation, campaign responses map to utm.mixin fields (source, medium, campaign) on the Lead record. The customer chooses the mapping strategy during scoping.