Architect Flow Timeout Logic Discrepancy in Performance Dashboard Metrics

Architect & Flows
1

My configuration keeps failing as expected within our primary Europe/Paris IVR architecture. The issue involves a specific discrepancy between the actual call routing behavior defined in Genesys Cloud Architect and the metrics reported in the Performance Dashboard. We are utilizing a complex flow structure with nested sub-flows to handle high-volume transactional calls. The main flow contains a ‘Get Input’ block configured with a strict 15-second timeout, followed immediately by a ‘Play Prompt’ block for an error message, and then a ‘Set Variable’ block to increment a retry counter. If the counter exceeds three, the flow routes to a specific queue. However, the Performance Dashboard consistently shows these calls as ‘Abandoned’ at the IVR level rather than being routed to the queue or counted as handled interactions, despite the logs showing successful variable updates and subsequent routing decisions. The dashboard metric ‘IVR Handled’ remains static while ‘IVR Abandoned’ spikes during peak hours in the Paris timezone. This suggests that the system is not registering the completion of the IVR journey before the timeout event triggers the abandonment logic in the reporting engine. We have verified that the ‘End Conversation’ action is not being called prematurely. The issue appears to be related to how the dashboard calculates the duration of the IVR segment versus the actual processing time of the nested sub-flows. The latency introduced by the sub-flow execution seems to push the total time beyond the threshold used by the reporting engine to classify the interaction, even though the user remains on the line. Is there a known limitation regarding how the Performance Dashboard aggregates metrics for flows with deep nesting and variable timeout configurations? We need to ensure that our service level agreements are accurately reflected, and currently, the dashboard data is causing significant confusion in our operational reporting. Any insights into the underlying calculation logic or configuration adjustments would be appreciated. Thank you.

2

Make sure you verify the genesyscloud_routing_queue configuration specifically the metrics block. The Performance Dashboard metrics are driven by the queue level settings, not just the Architect flow logic. If the queue is not explicitly configured to track wait_time and abandon_rate with the correct granularity, the dashboard will show discrepancies against actual call behavior. In Terraform, ensure the following configuration is applied to your queue resource:

resource "genesyscloud_routing_queue" "ivr_queue" {
 name = "Primary IVR Queue"
 description = "Queue for high-volume transactional calls"
 
 metrics {
 wait_time {
 unit = "seconds"
 value = 15 # Match your Get Input timeout
 }
 abandon_rate {
 unit = "percent"
 value = 5
 }
 }

 wrap_up_policy {
 type = "required"
 }
 
 outbound_enabled = false
}

The 15-second timeout in the Get Input block triggers an immediate exit if no input is received, but the dashboard metric for “Abandoned Calls” only counts if the caller hangs up before reaching an agent or a final disposition. If the flow routes to a sub-flow that plays a prompt and then disconnects, this is often logged as a “Handled” interaction in the flow logs but might appear as an anomaly in queue metrics if the queue’s outbound_enabled is false and no agent interaction occurred. Check the genesyscloud_flow resource to ensure the timeout action is correctly mapped to a disconnect or transfer that updates the disposition code. Also, validate that the genesyscloud_routing_settings for the user pool associated with this queue has the correct skills assigned, as mismatched skills can cause silent routing failures that skew metrics. Use the GC CLI to export the last 24 hours of flow logs: genesys cloud flows logs get --flowId <id> --startTime "2023-10-01T00:00:00Z" and compare the timeout events with the dashboard’s abandon count. This usually reveals if the discrepancy is due to metric aggregation lag or a misconfigured queue metric definition.

3

It depends, but generally… the dashboard aggregates at the queue level, ignoring internal flow logic. To see true timeouts:

  • Check if the queue tracks wait_time specifically.
  • Ensure the flow uses a dedicated queue for timeout handling.
  • Verify JMeter load doesn’t mask the 15s limit with queue delays.