WFM Queue Performance Metrics Discrepancy in Architect Flow

My current config is completely failing as expected within the Genesys Cloud Performance dashboard, specifically regarding the alignment of queue-level metrics and agent availability statuses. We are operating in the Europe/Paris timezone on the standard enterprise platform, utilizing complex Architect flows for our primary support queues. The issue manifests when agents are placed into a specific ‘Wrap-Up’ status via an Architect flow action, yet the Performance dashboard continues to report them as ‘Available’ for a duration that exceeds the configured wrap-up time limit. This discrepancy affects our real-time adherence calculations and distorts the service level percentage reported in the WFM integration feeds.

The specific flow in question triggers a ‘Set Agent Status’ action to ‘Wrap-Up’ with a maximum duration of 120 seconds. However, in the Queue Activity view, agents remain in the ‘Available’ pool until the 120-second timer expires, regardless of whether they manually end the wrap-up early. Furthermore, the ‘Available’ metric in the Performance dashboard does not reflect the immediate transition to ‘Unavailable’ that the Architect flow intends. This behavior is inconsistent with the expected logic where an agent entering a non-ready status should immediately decrement the available agent count. We have verified that the routing profiles are correctly configured and that no conflicting flow actions are overriding the status change.

We require clarification on whether this is a known latency issue within the Performance dashboard’s aggregation logic or if there is a specific configuration in the Architect flow that forces the dashboard to ignore the status change until the timer completes. The business impact is significant, as our WFM team relies on accurate real-time availability data for adherence reporting. Any insights into the underlying mechanism that controls how Architect flow status changes propagate to the Performance dashboard metrics would be greatly appreciated. We are currently unable to determine if this is a platform limitation or a misconfiguration in our flow design.

Make sure you are not relying on the standard genesyscloud_wfm_user_settings resource for real-time status overrides. The WFM API caches availability states, which creates a lag between the Architect action and the reporting engine. This discrepancy is common when using manual status changes via flows.

Instead, use the genesyscloud_flow resource with a specific Data Action to force a status refresh. The provider handles the synchronization better than raw API calls.

resource "genesyscloud_flow" "support_queue" {
 name = "Support Queue Flow"
 
 # Force status update on wrap-up
 actions {
 id = "update_status"
 type = "SET_USER_STATUS"
 properties = {
 statusId = var.wrap_up_status_id
 reasonId = var.wrap_up_reason_id
 }
 }
}

Do not use genesyscloud_wfm_user_settings for dynamic status changes during active calls. It causes drift and reporting errors. Stick to flow-based status updates for accurate metric alignment in the performance dashboard.