Status: Public Preview — behaviour may change.

What it does

Conversation orchestration watches every conversation from initiation through resolution and responds automatically when conditions change: wait times rising, queues filling, representatives signing out. Instead of static routing rules firing once, you write playbooks in natural language, each made up of a trigger event, conditions and actions. On publish, the system converts the playbook into a structured runtime format using a language model, and that runtime format is what actually executes.

Key facts

• Available for voice and messaging channels only; you pick Voice or Messaging per playbook in the Queues pane, and the context variables offered depend on that channel
• Playbooks consist of a trigger event, up to 10 conditions (each with up to 2 context variables), and a set of actions
• Seven trigger events: conversation waiting in queue, transferred to queue, routed to queue, consult to queue, representative signs in, timer elapsed, and direct inbound call offered to a user
• Conditions cover queue out of operating hours, all representatives signed out, estimated average wait time over a threshold, an individual conversation's wait time over a threshold, number of waiting conversations over a threshold, direct-dial call rejected/timed out/user unavailable, and a representative's presence status plus active conversation limit
• Actions go well beyond priority and overflow: change priority (0–10,000), transfer to another queue, transfer to an external number, offer callback, offer voicemail, keep unassigned, end conversation, expand assignment pool, assign to previously engaged / preferred / next available representative, and set user presence
• Supported scenarios: dynamic prioritisation (on transfer and on wait time), overflow handling (including direct inward dialled calls when the representative isn't available), preferred or previously engaged expert, keeping the same expert for returning asynchronous chats, and bullseye routing through user groups
• Overflow can now key off wait time in queue and queue position as well as representative availability, sign-in status and operating hours
• The prompt gallery shows six popular prompts by default, with templates grouped by scenario
• Playbooks are Draft (editable, inactive) or Active (live; changes need Save & Publish, and Save is disabled)
• Validation checks required fields, ranges (priority 0–10,000; time interval minimum 30 seconds), duplicate and conflicting conditions, and cross-playbook conflicts
• You can't have two active playbooks for the same scenario on the same queue; different scenarios on one queue can run together, each firing on its own trigger
• Requires a Pay-as-you-go plan backed by an Azure subscription (charged when the agent runs), unified routing, at least one queue and workstream, and a configured voice or messaging channel
• Dynamic prioritisation from playbooks doesn't apply to a queue that has custom prioritisation rules configured; remove them first
• Playbooks can be moved between environments through solution export and import

When to use / skip

Use this if you need adaptive routing that responds to live conditions without rebuilding workstream rules for each scenario, particularly across several queues with variable demand, or where closed queues, signed-out teams and direct-dial misses need a defined fallback.

Skip it if you have a single queue with stable traffic. The PAYG billing model means playbook execution is metered, so low-volume centres will likely find it overkill. Also skip it for any queue relying on custom prioritisation rules until you're willing to drop them.

Configuration decisions

• Which trigger events make business sense per queue: waiting, routed, transferred, consulted, timer-based or sign-in
• Priority score increments: the 0–10,000 range is wide, so agree a convention before deploying across queues
• Which overflow treatment per queue: transfer to queue, external number, callback, voicemail, keep unassigned or end conversation
• Fallback when the preferred or previously engaged representative isn't available: next available representative, or unassigned in queue for returning async chats
• Apply to scope: all queues, a list, or all except; the exclusion route is the tidy way to resolve a same-scenario conflict
• Whether different scenario playbooks share queues or are segmented by queue
• Who owns the canonical active playbook per queue and scenario
• Which presence status representatives should land in at sign-in, if you use the set-presence action

Gotchas

• Active playbooks are locked at Save. You must use Save & Publish, which goes live immediately. Cancelling reverts to the last published version.
• Cross-playbook conflicts only surface at publish. You can save a conflicting draft happily; the error appears when someone publishes, and the check is against other active playbooks only.
• The language model conversion can drift. Microsoft states that the converted runtime output might not fully capture your intent, and deviations show up only at runtime. Test and monitor, then revise the playbook.
• Deleting an active playbook stops orchestration for its queues immediately.
• Changing the channel on a draft playbook means updating the context variables and the corresponding prompt too.
• Migration is dependency-sensitive. The solution import fails if the queues and context variables a playbook references don't already exist in the destination. Add the CC User Prompt table to the solution, create or migrate the dependencies first, and check names match.
• Diagnostics need a custom query. There's no built-in dashboard for playbook execution; you query the conversation diagnostics data (Microsoft publishes sample queries).
• PAYG is mandatory. The Azure-backed plan must be set up before you can configure it, which is a blocker if procurement hasn't approved the subscription.
• Not for employment decisions. Microsoft's notice says the feature isn't intended to inform decisions about employees, and consent and monitoring obligations sit with the customer.

Consultant notes

• Clients consistently underestimate the queue-mapping exercise. Before any playbook is written, you need a definitive list of which queues handle which conversation types and their acceptable wait thresholds. Without that you end up with conflicting active playbooks and a messy publish process.
• Natural-language authoring demos well, but in UAT ambiguous prompts give inconsistent condition matching. Stick to the gallery templates and the "Tips for this playbook" guidance rather than freeform wording, and put the test conversations in the plan, not the hope.
• The trigger and action list has grown a lot during preview (timers, consult, sign-in presence, callback, end conversation). That's useful, but it also means more ways to fight your own routing; keep a one-page register of what each queue's active playbooks do.
• Preview behaviour changes before GA, particularly condition logic and the variables available per channel. Don't promise specific variables or actions to a client until GA, and raise the Azure subscription as a dependency early.

---

Worth revisiting at GA — trigger/condition/action coverage, supported channels and billing model may change materially from the preview release.