We’ve got a deployment in us-east-1 running Architect 2024.2.1 where a specific IVR path keeps dropping calls. The flow triggers a transfer to the main auto-attendant, but the transfer action returns a 503 Service Unavailable after exactly 4.2 seconds. Console shows the interaction ID, but the transfer never completes.
- The routing target points to the standard
main-aa queue.
- Queue status is healthy. Agent count sits at 42.
- Checked the Resource Center article on Transfer Actions Best Practices and confirmed the timeout is set to 30 seconds.
- API logs via
/api/v2/interactions/calls/{id}/transfers show the payload goes out clean. Status flips to FAILED with reason: target_unreachable.
There’s a known discussion on the community about similar routing loops, but that thread focuses on SIP trunk misconfigurations. This setup uses internal cloud-to-cloud routing. The admin UI shows the queue ID matches exactly. Tried rebuilding the transfer block. Cleared the flow cache. Doing jack all to fix it.
Screenshots attached below show the exact node configuration and the queue settings. The timeout slider looks normal, but the backend rejects it anyway.
One of the other flows in the same org handles this same transfer without issues. The only difference is the new flow uses a custom attribute to set the caller ID before routing. That attribute gets populated fine. The transfer block just dies.
Looking at the trace logs, the initial INVITE goes out, gets a 100 Trying, then drops to a 503. No retry logic kicks in. The Resource Center mentions a 503 usually points to a backend routing service overload, but our org traffic sits at 18% capacity.
[Screenshot: Transfer_Node_Config.png]
[Screenshot: Queue_Status_Healthy.png]
The flow validation passes green across the board. Trace output below:
2024-08-12T14:32:01Z [WARN] TransferAction: target_unreachable 503
2024-08-12T14:32:05Z [INFO] Session terminated
Mic stays hot on this one.
{
"action_type": "transfer",
"transfer_target": {
"target_type": "queue",
"target_id": "main-aa-queue-id",
"queue_name": "Main Auto-Attendant",
"routing_strategy": "longest_idle",
"timeout_seconds": 30,
"failover_action": "queue_prompt"
},
"preserve_context": true,
"wait_for_disconnect": false
}
Might want to verify the Transfer Target payload before assuming the queue is down. The 503 typically fires when the Routing Strategy doesn’t match the downstream queue config. It’s a common Architect Flow mismatch. Don’t use random routing on multi-tier IVRs. The system expects longest_idle or position. If the Queue Name has a trailing space, the handoff drops immediately.
Check the Timeout Settings in the debug trace. A 4.2 second cutoff usually means the Provisioning Check is stalling on the SIP INVITE. Bump the Timeout Seconds to 30 and wire up a Failover Action. You’ll see the interaction ID persist through the transfer once the session token refreshes. Leave the wait_for_disconnect flag disabled. It causes the port to hang on the SIP BYE. The Architect Flow handles the context handoff much cleaner when the timeout buffer is set correctly. Just verify the queue status in the admin console. The SIP trunk usually resets after a hard refresh. Cache sometimes sticks. Clear it manually.
The 503 response usually hits when the ROUTING ENGINE can’t resolve the TRANSFER TARGET because the target classification doesn’t match the underlying resource. You’re pointing the action at a queue identifier, but auto-attendants require a completely different resource type. The PIPELINE DEPLOYMENT process often flattens these distinctions during the export phase, which is why the console shows a healthy queue but the transfer still bounces.
First, you need to pull the actual Auto-Attendant resource ID instead of relying on the queue name. Run this against your tenant to grab the correct identifier. You’ll need the routing:autoattendant:read scope attached to your service account.
curl -X GET "https://api.mypurecloud.com/api/v2/routing/auto-attendants?name=main-aa" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json"
Second, you’ll notice the TRANSFER ACTION payload needs a structural shift. The ROUTING STRATEGY key actually gets ignored when targeting an auto-attendant, since AAs don’t use agent idle time logic. You’ll want to strip that out and flip the target type. Here’s how the corrected configuration should look in your Architect flow or your IaC export:
{
"action_type": "transfer",
"transfer_target": {
"target_type": "auto_attendant",
"target_id": "retrieved-aa-id-here",
"target_name": "Main Auto-Attendant",
"preserve_context": true,
"wait_for_disconnect": false
},
"failover_action": "play_prompt",
"failover_prompt_id": "queue-unavailable-prompt-id"
}
Third, verify your COMPLIANCE RULES aren’t blocking cross-region transfers if you’re deploying through a multi-region PIPELINE DEPLOYMENT. The logic breaks down pretty simply. The platform checks the TRANSFER TARGET classification before it even touches the queue capacity metrics. If it sees queue but the underlying resource is an auto-attendant, the routing service throws a 503 after the initial handshake timeout, which explains that exact 4.2 second delay. Honestly, the export tool does this more often than you’d expect. Just update the action node and re-run the validation script. The export usually handles the rest.