Demo Part 3 Step 4 Routing Queue AI Recording Tools Callback

Import: part-3-step-4-routing-queue-ai-recording-tools-callback.json

Goal

Add the final queue callback layer on top of the already combined routing, recording, and AI-tool scenario:

• queue announcements can enable callback
• dispatch can still serve a live waiting caller
• or it can call the customer back later

Changes Compared with Step 3

Added area	Why it matters
callback_on, play_callback	caller can explicitly enable callback on the queue entry
dial_customer, wait_customer, ringing_customer, break_customer, play_cust_unv	dispatch can reconnect the customer if the live caller is no longer present
callback-aware dispatch nodes	queue dispatch no longer assumes the customer leg is still live

Why This Works

• callback_on only marks the queue entry as callback-enabled. It does not remove the caller from the live queue by itself.
• queue still owns the caller-leg lifecycle. That is why wait_agent remains dial-scoped and does not need Master Leg ID.
• when dispatch happens, the workflow can first try the still-live caller path and only fall back to dial_customer if dispatch no longer has a live customer leg to bridge.
• callback is added last because it changes queue state and dispatch semantics more than any previous layer.

How to Test

1. Import and activate the workflow.
2. Put a caller into the queue.
3. Enable callback from the queue announcement.
4. Let the queue dispatch path run.
5. Test both the still-live-caller case and the callback-customer case.

Expected Result

Situation	Result
caller is still connected	dispatch bridges the live waiting caller
callback was enabled and the live caller is gone	dispatch uses dial_customer to reconnect the customer
callback customer does not answer	the workflow plays the customer-unavailable prompt and breaks the attempt cleanly

Final Result

This example is the assembled walkthrough endpoint. The canonical full workflow remains Full Demo.