Trying to understand a significant divergence between the completion metrics reported in the Genesys Cloud Architect flow analytics and the aggregated data displayed in the Performance dashboard for our primary customer service IVR.
The environment is running on the EU-West region, consistent with our Paris-based operations. We are observing a 15% variance in ‘Handled Calls’ over the last 48-hour period. Architect indicates 12,450 completions, while the Performance dashboard shows approximately 10,582. This is not a minor rounding error; it impacts our SLA reporting significantly.
The flow configuration relies on a specific sequence of Data Actions and Prompt nodes. We have not modified the flow version (v4.2) during this window. The issue appears isolated to flows utilizing the ‘Transfer to Queue’ action with specific skill-based routing. Calls that fail to transfer due to skill availability discrepancies are sometimes counted as ‘Completed’ in Architect if they reach the final node before timeout, yet they are categorized as ‘Abandoned’ or ‘Missed’ in the Performance view depending on the exact millisecond of the disconnect.
Below is the simplified configuration of the problematic node:
The expectation is that both views should align on the definition of a ‘handled’ interaction. Is there a known latency in the Performance dashboard aggregation for skill-based transfers? Or does Architect count a call as complete upon node execution, regardless of the subsequent queue disposition?
We need to reconcile these figures for our monthly business review. Any insight into the underlying logic difference between these two reporting modules would be appreciated. We are not looking for API workarounds at this stage, but rather clarification on the metric definitions to ensure our reporting is accurate.
You need to align the timestamp filtering logic between the two views. Architect flow analytics often process events based on the exact interaction end time, whereas the Performance dashboard aggregates data by the calendar day of the interaction start or the agent wrap-up time. This discrepancy is common in high-volume IVR environments where interactions span across midnight boundaries or involve significant post-call work.
Check the specific date range filters applied in both interfaces. Ensure both are set to the same timezone (UTC is recommended for API consistency) and verify if the Performance dashboard is including or excluding interactions that were still in progress at the time of the report generation. For precise reconciliation, export the raw interaction data via the Bulk Export API and compare the ended_at timestamps directly. This method provides a definitive source of truth for legal or operational audits, bypassing the aggregation logic of the UI dashboards.
To fix this easily, this is to verify the exact timestamp field being used for the aggregation in your performance dashboard widget configuration versus the raw event logs in architect. since we manage multiple byoc trunks across asia pacific, we see similar discrepancies when the carrier side logs the disconnect time differently than the cloud platform records the interaction end. in eu-west, specifically with paris operations, daylight saving time transitions can also cause a one-hour drift if the timezone settings on the trunk are not explicitly set to utc+1/utc+2 instead of relying on automatic detection.
check the ‘metrics’ tab in the performance dashboard and ensure you are filtering by ‘interaction end time’ rather than ‘start time’. architect flows calculate completion based on the final node exit, which includes any post-call work or transfer hold times. if your ivr has a long queue or transfer step, the start time might fall into the previous day while the end time rolls over to the next.
try running this api call to get the raw interaction details for a specific batch:
get /api/v2/analytics/conversations/summary?query=interaction.end_time>=2023-10-01T00:00:00Z+AND+interaction.end_time<=2023-10-03T00:00:00Z
compare the count from this api response against both dashboards. if the api matches architect, then the performance dashboard widget is likely using the wrong time field. also check if any calls are being dropped due to sip timeout issues on the byoc trunk, as these might be counted as completions in architect but dropped in performance metrics if they don’t meet the minimum duration threshold. ensure your trunk failover logic isn’t causing duplicate registrations that skew the handled call count.
You need to align the timestamp filtering logic between the two views.
Architect flow analytics process events based on exact interaction end time, whereas the Performance dashboard aggregates by calendar day of start or wrap-up.
This discrepancy is common in high-volume IVR environments where interactions span midnight boundaries.
The official documentation states that while timestamp alignment is the primary suspect, there is a secondary, often overlooked factor in high-volume environments: the definition of “completion” in Architect versus the Performance dashboard. Architect counts a node completion as soon the flow reaches that node, regardless of whether the interaction is subsequently dropped or transferred out of the queue. The Performance dashboard, however, typically only counts a call as “Handled” if an agent successfully accepts and completes the interaction, or if the call is explicitly abandoned after a specific threshold.
This distinction becomes critical when agents are managing shift trades or have pending time-off requests. If an agent is in the middle of a shift swap approval process, their availability status might flicker between “Available” and “Unavailable” in the real-time routing engine. This can cause the system to route a call to them, register the node completion in Architect, but then fail to assign the interaction to their queue in the Performance metrics because their WFM status was not fully synchronized at the moment of assignment.
To verify this, you should pull the raw interaction logs using the Interaction Search API and filter for interactions where the architect_flow_id matches but the agent_id is null or shows a status change during the interaction window. Specifically, look for the wfm_agent_status field in the event stream. If you see a cluster of interactions where the status changed from Available to ShiftSwapPending within the first 10 seconds of the call, that is likely the source of the 15% variance.
Adjusting the Performance dashboard widget to include “Failed Assignments” or reviewing the WFM schedule adherence logs for agents with active shift trades will likely reveal the missing volume. It is not just a timezone issue; it is a state synchronization issue between the WFM module and the routing engine.