The GET /api/v2/interaction/queues endpoint is returning a queueDepth of 45 for the Sales-Priority queue, yet the WFM dashboard shows only 12 agents logged in with Available status immediately after the weekly schedule publish at 06:00 CST. The discrepancy persists for approximately 15 minutes before self-correcting, causing a significant drop in service level during the morning rush. We are using the standard Genesys Cloud Predictive Routing configuration with no custom scoring rules applied to this specific queue. The agents involved are part of a shift swap that was approved via the self-service portal two days prior, and their schedule adherence records confirm they are present and logged into the correct work mode.
Investigating the integration logs reveals no errors during the initial wfm.schedule.publish event, but the analytics.interactions.queue metrics show a sudden spike in waitTime that correlates exactly with the queue depth inflation. We have verified that the routing.profile settings for these agents are correct and that no wrapUp timers are interfering with their availability status. The issue seems isolated to agents who have participated in a shift trade within the last 72 hours, as those on static schedules report accurate queue depths instantly. Has anyone encountered a synchronization lag between the WFM schedule engine and the Predictive Routing capacity calculation? We are running version 2023-11 of the platform and have tried invalidating the local cache, but the problem recurs every Tuesday when the new schedules go live. Any insights into why the routing engine might be double-counting capacity or misinterpreting the shift swap data would be appreciated.