We’ve got a really frustrating issue impacting the rollout of the new post-call survey flow - and naturally, stakeholders are already questioning the Q3 adoption numbers. It’s centered around the trigger condition in Architect. The flow should be initiating a survey for all calls ending with a disposition of ‘Completed - Positive Outcome’, but it’s consistently missing about 30-40% of those calls.
The Architect flow itself is pretty standard. It’s a simple ‘Start’ node, then a ‘Voice Call Ended’ event node, followed by a ‘Condition’ node evaluating the call disposition. If disposition equals ‘Completed - Positive Outcome’ it es to the survey IVR. Then a ‘Disconnect’ node. Nothing fancy. We validated the disposition values are correct in the historical call data, so it isn’t a data issue.
What’s weird is the reporting. The ‘Call Detail Records’ show the disposition being correctly set. The ‘Historical Call Search’ confirms the disposition is ‘Completed - Positive Outcome’. But the survey completion rate is significantly lower than expected. It’s like the condition isn’t evaluating correctly sometimes.
I checked the ‘Execution History’ for a few impacted calls, and it shows the ‘Condition’ node being evaluated, but it’s not always ing to the survey. Sometimes it just goes straight to the ‘Disconnect’ node. No errors logged in the Architect execution history itself.
We’re on Genesys Cloud build 2024.10.12, US East region. I’ve triple-checked the spelling of the disposition value in the condition - it’s exact. Tried recreating the flow from scratch, but the problem persists. I even tried using a regex in the condition, just in case there were hidden characters, but still nothing.
This is delaying the agent training on the new survey process, because we can’t reliably demonstrate the flow working end-to-end. The training plan outlined a 90% completion rate after the first week, and we’re currently at 65%. Management’s not thrilled. It’s making a mess of the adoption metrics.
Anyone else running into odd behavior with Architect condition nodes? The console is showing no obvious errors.
The documentation states that trigger conditions in Architect flows “are evaluated in real time as the session transitions between states” - this means timing is critical. The missing calls suggest the disposition isn’t being fully settled before the trigger evaluates.
Cause:
The disposition update isn’t fully propagated to the session data before the trigger condition runs. Genesys Cloud’s data synchronization isn’t always immediate. It’s asynchronous - meaning the disposition is eventually consistent, but not instantly. Trigger condition → disposition not settled → flow not triggered. We saw this in INC-4471 - a similar issue with a transfer condition.
Solution:
Add a short delay before the survey trigger. A 1-2 second delay should give the disposition time to settle. You can achieve this using a ‘Wait’ activity in Architect. Configure it to wait 1-2 seconds.
Here’s the relevant config for the Wait activity:
{
"type": "Wait",
"name": "Wait for Disposition to Settle",
"durationSeconds": 2,
"durationType": "Seconds"
}
Place the ‘Wait’ activity immediately before the survey trigger condition in the flow.
Alternatively, you can try using a session variable to store the disposition. Instead of directly evaluating the disposition on the call, set a session variable when the disposition is updated. Then, trigger the survey based on the session variable. The documentation recommends this pattern for handling asynchronous data updates. It’s more involved, but more reliable.
Platform SDK for JS can miss disposition updates. Cause: disposition isn’t fully settled before trigger evaluation - data sync isn’t immediate. Solution: add a 2-3 second delay before the survey trigger using a Wait activity.
i think the wait activity is good idea - the earlier reply say about data not sync yet.
just a hunch - maybe the disposition field is not saved correct in SFDC? i see sometimes the API call get error 500 when we try to update case from the CTI adapter. you check the debug log in apex? it show if the field is update or not.
Wait activities are a bandage, not a fix - the disposition update propagation is the root.
Cause: The architectFlow.trigger evaluation isn’t awaiting the full settlement of the call.disposition attribute - data races are common. The earlier reply correctly identifies the asynchronous nature of the platform’s data synchronization.
Solution: Implement a custom eventBridgeRule action. Monitor for session.stateChange events where session.state equals ‘DISCONNECTED’ and session.call.disposition equals ‘Completed - Positive Outcome’. The action should then queue a delayed trigger to the post-call survey flow by executing the flow. This ensures the disposition is fully settled before survey initiation.