Adherence gaps after shift trades in Management Units

Genesys Cloud WFM
1

Hi all, there’s a weird discrepancy happening with our adherence reporting after agents complete shift trades. We’ve got a massive BPO environment with about 5000 agents, and we’re seeing cases where the scheduled shift updates in the calendar, but the adherence engine still thinks the agent is on their original shift. This is causing a huge amount of “Out of Adherence” alerts for people who actually traded their shifts legally.

It’s creating a real headache for the team leads because they’re seeing red on the dashboard for agents who are actually clocked in and working. The shift trade is approved, the calendar looks correct, but the real-time adherence just won’t sync.

Here is the environment info and what’s been tried:

  • Org: Genesys Cloud (America/New_York)
  • Setup: Multiple Management Units across different BPO lines of business
  • Attempted: Verified the trade was approved in the WFM UI
  • Attempted: Refreshed the agent’s status in the real-time view
  • Attempted: Had a developer check the /api/v2/workforcemanagement/businessunits/{businessUnitId}/shifttrading/trades/evaluate/jobs endpoint to see if the evaluation job actually finished

Does the system require a specific sync interval before adherence catches up to a trade? Or is there a setting in the Management Unit configuration that controls how quickly these trades reflect in real-time?

1 Like
2

PureCloudPlatformClientV2 is the way to go here if you’re trying to automate the cleanup. The issue is likely that the shift trade is visually updated in the calendar, but the adherence engine hasn’t processed the state change for the actual agent record. It’s a known gap where the schedule update doesn’t always trigger an immediate adherence recalculation.

To fix this, you’ll want to use the adherence explanations endpoints to manually bridge the gap. You can send a POST to /api/v2/workforcemanagement/agents/{agentId}/adherence/explanations to tell the system why the agent isn’t on their original shift. Just a heads up: if you don’t provide a valid explanation ID or reason code, the adherence engine might still flag it as a gap.

If you need to verify the trade state first, try the POST /api/v2/workforcemanagement/businessunits/{businessUnitId}/shifttrading/trades/evaluate/jobs endpoint. It’ll let you see if the trade is actually finalized or just pending.

1 Like