How handoff routes
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 theincident record:
title—<classification> - <customer name or email>(falls back toSupport - Anonymousif neither is set).description— header lines forChannel,Summary,Classification,Sentiment, Customer Details (name, email, phone), followed by the full AI-to-customer transcript with timestamps.prioritycode— thedefault_priorityyou set in settings (1–4). Defaults to2(Medium).[email protected]— the linked contact (see below).[email protected]— thedefault_owner_idyou set, if any.[email protected]— thedefault_queue_idyou 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 '<email>'. If a match comes back, OpenCX links the incident to that contact. - Create — If no match, OpenCX creates a new contact with
firstname/lastnamesplit from the session name,emailaddress1,mobilephonefrom the session, anddescription: Created from chat session <session_id>. - 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(<id>). Leave blank to let Dynamics routing rules assign. |
default_queue_id | Queue GUID | Written as /queues(<id>). 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. |
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 anoc_liveworkitem with:
nameandcustomerInfo.name— the session name (orAnonymous).email/customerInfo.email— the session email, if any.subject— the AI’s session summary.workstreamId— yourdefault_queue_idfrom settings (used as the workstream).contextVariables—sessionIdandchannel, so the Omnichannel routing rules on your side can branch on them.
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 |
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 withstatecode: 1 (Resolved) and statuscode: 5 (Problem Solved). Reps can reopen the incident from Dynamics — OpenCX does not prevent it.
Related Documentation
Connect to OpenCX
Paste credentials and run Test & Save.
AI Chat Widget in Dynamics 365
Web chat → Omnichannel live work item.
AI Email Support in Dynamics 365
Email → Incident with transcript and linked contact.
Troubleshooting
Routing lands on the wrong entity, unassigned incidents, 403 on create.