How does the Transfer to Queue node actually process fallback logic when the primary queue drops below the WEM forecast threshold? We’re running Architect 2023.12 build 184.2 in the JP region. The flow hits a Split node first. It checks a custom attribute called wem_staffing_level. If the value returns low, routing moves to a secondary queue via the Transfer to Queue node. Instead of dropping to the fallback, the contact just disconnects. It’s throwing NODE_EXECUTION_FAILED: QUEUE_TRANSFER_TIMEOUT alongside a 408 response from the routing service.
In CIC we used to handle this by setting a priority skill override in the Attendant console. That setup automatically bumped the call to the overflow group without ever touching the media stream. Here the Architect flow just hangs for exactly twelve seconds before killing the leg. Mic stays hot on the agent side while the customer hears dead air.
[screenshot of flow architecture attached]
The Get Data node pulls the staffing metric from /api/v2/wfm/schedules/summary every thirty seconds. Cache is set to sixty. The payload doesn’t show any schema mismatches. We’ve patched it with a simple retry . If the transfer fails, it plays a short prompt and retries the Get Data node three times before finally routing to voicemail. Doing jack all to fix the root cause, but it keeps the drop rate under two percent.
Logs indicate the routing service rejects the queue ID because the WEM engine hasn’t updated the agent availability flag yet. Timestamp mismatch sits at about four seconds. Flow ID is 8f3a2c1b-9d4e-4a1f-b7c8-2e5f6a1b3c4d. Node ID is transfer_secondary_queue_02.
The NODE_EXE error fires when the Transfer to Queue node switches routing before the media session initializes. WEM attributes don’t sync instantly across Architect. You’ll need to drop a 2-second Delay node after the Split to let wem_staffing_level settle. Messy edge case. Stops the premature disconnect.
If calls still drop, check the Recording API state. Queue transfers kill the active audio stream when recording policies flip. The workaround forces a Stop Recording action before the Transfer node, then restarts it on the fallback queue. Keeps the voice biometric hash intact.
[Screenshot: Architect flow showing Delay → Stop Recording → Transfer to Queue]
The v2.1 Routing API will cache these attributes natively. Until then, that delay plus the recording reset handles it. Leaves the RTP stream hanging otherwise.
// Verify WEM scope
const role = await platformClient.getSecurityApi().getSecurityRole('wem-service-account');
It’s risky using a Delay node. It just hides the latency. If the WEM_SERVICE_ACCOUNT lacks the SCHEDULE_READ scope, the attribute stays null. The routing logic fails instantly. Fix the PERMISSIONS instead of adding wait times.
The NODE_EXE error usually fires when the Transfer to Queue node tries to route before the WEM attribute actually populates. In Zendesk, the routing rules used to wait for ticket fields to update automatically. Genesys Cloud flows run much faster, so you’ll need to force a sync step. The wem_staffing_level attribute needs a moment to move from the WEM service into the contact data. It does not update instantly.
Try mapping the value through a Set Contact Attribute node first. Force a local variable. This bypasses the direct attribute read timeout that causes the drop. Here is the config pattern that works during migrations:
{
"action": "SET_ATTRIBUTE",
"target": "local_staffing_var",
"source": "wem_staffing_level",
"scope": "CONTACT"
}
After the set action, use a Split node to check if local_staffing_var equals low. Route to the secondary queue only if the check passes. If it fails, attach a Retry node with a 1500 millisecond interval. It catches the sync gap without blocking the whole flow.
Does the secondary queue actually have a different recording policy? Sometimes the disconnect happens because the Transfer to Queue node tries to change the recording state while the media is still binding. Check the Queue settings under Media and Recording. If the fallback queue has Record from start and the primary had Agent answered, the media session just drops. It’s a common trap when moving digital channels from Zendesk to GC.
What timezone is the WEM schedule actually running in? Berlin time or the JP region time? WEM attributes sometimes pull the wrong shift if the org timezone and the schedule timezone do not match. The forecast threshold might be reading zero agents instead of low. You don’t need a Delay node if you handle the variable mapping correctly. Check the contact log before the split node fires.