> ## Documentation Index > Fetch the complete documentation index at: https://docs.open.cx/llms.txt > Use this file to discover all available pages before exploring further. # Conversations in Dynamics 365 > How OpenCX routes handoffs into Dynamics 365 incidents or Omnichannel live work items, what gets written, and how to trace it back. Every handoff to Dynamics 365 takes one of two paths: a real-time **live work item** in Omnichannel for Customer Service, or a **case incident** in the core Customer Service app. OpenCX picks the path automatically from the OpenCX channel. ## How handoff routes ```mermaid theme={"dark"} flowchart LR A[OpenCX session hands off] --> B{Channel} B -- web / sms / whatsapp --> C[Omnichannel live work item] B -- phone / email / other --> D[Incident + linked contact] ``` The routing rule is fixed: `web`, `sms`, and `whatsapp` flow into Omnichannel; everything else flows into an incident. You can't override it per session — the channel of the OpenCX session decides. ## Incident contents When a handoff lands as an incident, OpenCX writes these fields on the `incident` record: * **`title`** — ` - ` (falls back to `Support - Anonymous` if neither is set). * **`description`** — header lines for `Channel`, `Summary`, `Classification`, `Sentiment`, **Customer Details** (name, email, phone), followed by the full AI-to-customer transcript with timestamps. * **`prioritycode`** — the `default_priority` you set in settings (1–4). Defaults to `2` (Medium). * **`customerid_contact@odata.bind`** — the linked contact (see below). * **`ownerid@odata.bind`** — the `default_owner_id` you set, if any. * **`queueid@odata.bind`** — the `default_queue_id` you set, if any. * **Your `ticket_properties`** — any extra Dynamics fields you want populated, spread onto the payload as-is. ## Contact handling OpenCX keeps one Dynamics contact per customer email: * **Lookup** — OpenCX queries `contacts?$filter=emailaddress1 eq ''`. If a match comes back, OpenCX links the incident to that contact. * **Create** — If no match, OpenCX creates a new contact with `firstname`/`lastname` split from the session name, `emailaddress1`, `mobilephone` from the session, and `description: Created from chat session `. * **No email** — If the session has no email at all (anonymous widget visitor, SMS-only session with no captured email), the incident is created **without a linked contact**. Reps can link one manually after the fact. ## Defaults you can set per org These live in the Dynamics integration row and are applied on every incident: | Setting | Type | Effect | | ------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `default_priority` | integer 1–4 | Written as `prioritycode`. Defaults to `2` (Medium). | | `default_owner_id` | Systemuser GUID | Written as `/systemusers()`. Leave blank to let Dynamics routing rules assign. | | `default_queue_id` | Queue GUID | Written as `/queues()`. Leave blank to skip queue assignment. | | `ticket_properties` | JSON object | Merged into the incident payload. Use integer codes for option sets, and full `/entity(guid)` paths for any additional `@odata.bind` fields. | Incidents already exist in Dynamics — OpenCX doesn't invent new fields. Every key in `ticket_properties` must be a real column or lookup the Application User can write. ## Omnichannel live work items For web, SMS, and WhatsApp handoffs, OpenCX POSTs an `oc_liveworkitem` with: * `name` and `customerInfo.name` — the session name (or `Anonymous`). * `email` / `customerInfo.email` — the session email, if any. * `subject` — the AI's session summary. * `workstreamId` — your `default_queue_id` from settings (used as the workstream). * `contextVariables` — `sessionId` and `channel`, so the Omnichannel routing rules on your side can branch on them. The returned `oc_liveworkitemid` is stored as `dynamics365_chat_id` on the OpenCX session. ## Observability fields | Surface | Field | Value | | --------------------- | --------------------------- | --------------------------------------------------------------- | | OpenCX session `meta` | `dynamics365_incident_id` | Incident GUID (case handoffs) | | OpenCX session `meta` | `dynamics365_ticket_number` | Human-readable ticket number Dynamics auto-generates | | OpenCX session `meta` | `dynamics365_chat_id` | `oc_liveworkitemid` (chat handoffs) | | OpenCX session `meta` | `dynamics365_chat_status` | `initiated` once the live work item posts | | Dynamics contact | `emailaddress1` | Customer email — the trace key for dedupe | | Dynamics incident | `description` header | `Channel`, `Classification`, `Sentiment` — reps filter on these | Search either `dynamics365_incident_id` or `dynamics365_ticket_number` in Dynamics advanced find to jump to the record from an OpenCX session. ## Closing the case When the OpenCX session resolves, OpenCX PATCHes the incident with `statecode: 1` (Resolved) and `statuscode: 5` (Problem Solved). Reps can reopen the incident from Dynamics — OpenCX does not prevent it. *** ## Related Documentation Paste credentials and run Test & Save. Web chat → Omnichannel live work item. Email → Incident with transcript and linked contact. Routing lands on the wrong entity, unassigned incidents, 403 on create.