Just noticed that the adherence engine is flagging agents for ‘Unscheduled Activity’ immediately after a shift swap is approved via the WFM API. We are using the Chicago cluster and publishing weekly schedules via the standard bulk-publish endpoint, but something seems to be breaking in the handoff between the shift-trade module and the real-time adherence calculation service. When an agent successfully completes a shift swap through the agent self-service portal, the schedule record updates correctly in the historical view, yet the live adherence dashboard still reflects the original shift boundaries for that specific interval. This results in a false positive penalty being applied to the agent’s performance score for the duration of the swapped hours. I have verified that the API response for the shift trade endpoint returns a 200 OK with the correct start and end times, and the schedule version ID increments as expected. However, querying the adherence events endpoint for that specific agent during the swapped window shows no matching schedule segment, causing the system to interpret the agent’s logged-in status as unscheduled work. We are running the latest WFM API version (v3) and have ensured that the time zone settings are consistently set to America/Chicago across all relevant configurations. The issue appears to be isolated to shifts that cross midnight or involve complex break configurations, as simpler day-shift swaps seem to propagate correctly to the adherence engine within the expected 5-minute sync window. I have checked the audit logs and found no errors related to the schedule publication job itself, but there are intermittent 500 Internal Server Errors when the adherence service attempts to reconcile the new schedule version with the existing performance metrics. Has anyone encountered a similar latency or data synchronization issue between the WFM schedule publishing workflow and the adherence calculation engine? Any insights on whether this is a known limitation of the current API version or a configuration issue we need to address on our end would be greatly appreciated. We need to resolve this quickly as it is impacting agent morale and performance reporting accuracy for the upcoming quarter.