WEM Adherence - State Stuck in NOT_READY Despite Agent Available

Hey all,

So we’ve got agents showing as NOT_READY in WEM, specifically stuck in that state, even though they’re clearly available in the agent desktop - handling calls, chats, the whole nine yards. It’s like the adherence data hasn’t caught up. It’s happening intermittently, but it’s enough to skew our REALTIME metrics, which is, naturally, frustrating.

I’m pulling adherence data via the adherence query endpoints. We’re using the Java SDK, version 3.0.153.0. The query parameters seem correct - filtering by agent ID, interval length, and state - I’ve triple-checked. The API response does show the NOT_READY state, so it’s not a client-side display issue.

The Architect flows are standard - simple IVR routing, nothing fancy with wrap-up times or custom states. We have configured POST_CALL_PROCESSING to be 30 seconds, but it shouldn’t affect the immediate availability. The agents are assigned to a queue with a SERVICE LEVEL AGREEMENT of 20/80. This makes reporting a nightmare. Anyone else seeing similar issues? It feels like the API is just lagging behind state changes. Honestly, the whole adherence API could really use a refresh - it’s a bit of a mess.

ok so are you filtering by user.id or user.username in the api call? we’ve seen the adherence data lag when the user id isn’t consistent across systems → the platform api relies on a precise match for accurate state reporting. double-check the interval parameter too - a too-small interval can cause missed data points.

That fix worked - we were filtering by username instead of user ID, which, honestly, is a ridiculous design choice on that endpoint. Switched to the ID and the states are updating properly now, though I still maintain the documentation is… lacking. It’s still irritating how often the API forces you to work around basic inconsistencies.