… 2 unchanged lines …
  
  ## What it does
  
- Conversation orchestration actively monitors every conversation throughout its lifecycle — from queue entry through resolution — and responds automatically when conditions change. Instead of static routing rules firing at a single point, you define playbooks that watch for specific trigger events (wait time thresholds, no agents available, conversation transferred) and execute actions like priority boosts or overflow transfers. Playbooks are written in natural language and executed by the Service Operations Agent.
+ 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** in the current preview release (earlier previews were limited to voice and live chat)
- - Playbooks consist of a **trigger event**, up to **10 conditions** (with up to 2 context variables each), and a set of **actions**
- - Supported trigger events include: conversation waiting in queue, conversation transferred
- - Supported actions include: increase priority (0–10,000 range), trigger overflow (route to voicemail, transfer to queue, redirect to number)
- - Supported scenarios include dynamic prioritisation, overflow handling (now factoring wait time in queue and queue position alongside representative availability, sign-in status and operating hours), bullseye routing through user groups, and assigning to a preferred or previously engaged expert
- - The preferred-expert scenario now covers **keeping the same expert for returning asynchronous chats**, checking the expert's presence status and active conversation limits before reassigning
- - The prompt gallery now surfaces **six** popular prompts by default (up from three), with templates grouped by scenario
- - Playbooks have two statuses: **Draft** (editable, not active) and **Active** (live, changes require Save & Publish)
- - You cannot have two active playbooks for the **same scenario on the same queue** — this is a hard conflict
- - Different scenarios on the same queue (e.g. wait-time prioritisation + availability overflow) **can** run simultaneously
- - Requires a **Pay-as-you-go Azure subscription** — consumption billing applies when the agent runs
- - Requires unified routing, at least one queue and workstream, and a voice or messaging channel configured
- - Dynamic prioritisation from playbooks is **incompatible with custom prioritisation rules** on a queue — remove custom rules before enabling
+ - 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 logic that responds to real-time conditions — queues filling up, wait times spiking, agents going offline — without manually re-configuring workstream rules for each scenario. It's particularly useful for organisations handling variable demand across multiple queues where static overflow rules aren't granular enough.
+ 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 only have a single queue or predictable, stable traffic. The PAYG billing model means every playbook execution costs money; low-volume contact centres will likely find this overkill. Also skip it if any of your queues rely on custom prioritisation rules — the two are mutually exclusive.
+ 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 for each queue (wait time threshold vs. immediate availability check)
- - Priority score increments — the 0–10,000 range is wide; agree an internal convention before deploying across multiple queues to avoid conflicting priorities
- - Overflow actions per queue: voicemail, transfer to another queue, redirect to a number — this needs to be pre-agreed with operations
- - Whether to run different scenario playbooks on the same queues or segment by queue
- - How to handle the conflict rule for same-queue/same-scenario playbooks — who owns the canonical active playbook per queue
+ - 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
  
- - **Editing active playbooks is locked at Save** — you must use Save & Publish, which immediately goes live. There's no staging for active playbooks outside of deactivating them first.
- - **Cross-playbook conflicts are only detected at publish time**, not when saving as draft. You can happily save a conflicting draft; the error only surfaces when someone tries to publish.
- - **Diagnostics require a custom query** — there's no built-in dashboard for playbook execution tracking in the current preview. You need to set up queries against the conversation diagnostics data in Application Insights.
- - **Removing custom prioritisation from a queue is permanent** — if you switch a queue to playbook-driven prioritisation and then deactivate the playbook, the queue has neither mechanism active until something is re-configured.
- - **PAYG billing is mandatory** — the Power Platform Pay-as-you-go plan must be set up with an Azure subscription before you can configure conversation orchestration. This is a blocker if procurement hasn't approved the Azure subscription.
+ - **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 what their acceptable wait thresholds are. Without that, you end up with conflicting active playbooks across queues and a chaotic publish process.
- - The natural-language playbook authoring sounds great in demos, but in UAT you'll find that ambiguous prompts produce inconsistent condition matching. Spend time with the client defining precise trigger wording using the provided templates rather than freeform language.
- - The PAYG billing model catches procurement teams off-guard in scoping. Raise it as a dependency early — the Azure subscription approval can take weeks in regulated industries, and it's a hard blocker.
- - Preview features in D365 CC have a history of behaviour changes between preview and GA, particularly around condition logic and the context variables available per channel. The channel coverage has already broadened from live chat to all messaging during preview, so don't make firm promises about specific variable or channel support until GA.
+ - 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 — condition types, supported channels, and billing model may change materially from the preview release.*
+ *Worth revisiting at GA — trigger/condition/action coverage, supported channels and billing model may change materially from the preview release.*
  

    … 6 unchanged lines …
  
  ## Key facts
  
- - Available for **voice and live chat channels only** in the current preview release
+ - Available for **voice and messaging channels only** in the current preview release (earlier previews were limited to voice and live chat)
  - Playbooks consist of a **trigger event**, up to **10 conditions** (with up to 2 context variables each), and a set of **actions**
  - Supported trigger events include: conversation waiting in queue, conversation transferred
  - Supported actions include: increase priority (0–10,000 range), trigger overflow (route to voicemail, transfer to queue, redirect to number)
+ - Supported scenarios include dynamic prioritisation, overflow handling (now factoring wait time in queue and queue position alongside representative availability, sign-in status and operating hours), bullseye routing through user groups, and assigning to a preferred or previously engaged expert
+ - The preferred-expert scenario now covers **keeping the same expert for returning asynchronous chats**, checking the expert's presence status and active conversation limits before reassigning
+ - The prompt gallery now surfaces **six** popular prompts by default (up from three), with templates grouped by scenario
  - Playbooks have two statuses: **Draft** (editable, not active) and **Active** (live, changes require Save & Publish)
  - You cannot have two active playbooks for the **same scenario on the same queue** — this is a hard conflict
  - Different scenarios on the same queue (e.g. wait-time prioritisation + availability overflow) **can** run simultaneously
    … 28 unchanged lines …
  - 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 what their acceptable wait thresholds are. Without that, you end up with conflicting active playbooks across queues and a chaotic publish process.
  - The natural-language playbook authoring sounds great in demos, but in UAT you'll find that ambiguous prompts produce inconsistent condition matching. Spend time with the client defining precise trigger wording using the provided templates rather than freeform language.
  - The PAYG billing model catches procurement teams off-guard in scoping. Raise it as a dependency early — the Azure subscription approval can take weeks in regulated industries, and it's a hard blocker.
- - Preview features in D365 CC have a history of behaviour changes between preview and GA, particularly around condition logic and the context variables available per channel. Build this into your testing plan and don't make firm promises about specific variable support until GA.
+ - Preview features in D365 CC have a history of behaviour changes between preview and GA, particularly around condition logic and the context variables available per channel. The channel coverage has already broadened from live chat to all messaging during preview, so don't make firm promises about specific variable or channel support until GA.
  
  ---