Just noticed that the Workforce Management adherence reports are showing significant gaps for agents associated with specific BYOC trunk groups during our recent failover drills. We are managing 15 BYOC trunks across the Asia/Singapore region, and while the SIP registration stability is generally acceptable, the correlation between carrier failover events and WFM state changes is broken. Specifically, when the primary carrier drops and traffic shifts to the secondary trunk via our outbound routing logic, the agent status in Genesys Cloud transitions to ‘Not Ready’ but the WFM API (/api/v2/wfm/api/schedules) fails to log the corresponding break or non-compliant interval. The error manifests as a silent failure in the adherence engine rather than a hard 500 error. We have verified that the SIP logs show successful registration on the secondary trunk within 200ms, yet the WFM dashboard shows a 15-minute gap in logged hours for those specific agents. This is not a universal issue; it only affects agents mapped to the trunk groups configured with aggressive failover thresholds. We are using the standard WFM integration without custom middleware, and the issue persists across both the Genesys Cloud UI and the direct API calls. The timestamp mismatch suggests that the WFM service is not receiving the state change event from the routing engine when the trunk ID changes. We have checked the audit logs and found no corresponding entries for the state transition during the failover window. The problem seems isolated to the Singapore region instances, as our US-based trunks do not exhibit this behavior under similar failover conditions. This discrepancy is causing our compliance metrics to skew significantly, leading to potential payroll calculation errors. We need to understand if this is a known limitation of the WFM engine when dealing with dynamic trunk assignments or if there is a configuration gap in our outbound routing profiles. Is there a specific API endpoint or logging level that can expose the raw state transition events during a trunk swap? We are looking for a way to reconcile the WFM data with the actual call flow logs to automate the correction of these adherence gaps.