I am currently investigating a discrepancy in our ‘WFM Historical Adherence’ reports. I am seeing that some agents are being flagged as ‘Non-Adherent’ for their entire shift, even though our interaction logs show they were actively taking calls and chats during that time. I suspect that the ‘Presence-to-Activity’ mapping in the WFM business unit is not correctly synchronized with our actual agent statuses. How can I audit the raw presence data used by the adherence engine to identify where the mismatch is occurring?
I love troubleshooting these data issues! To audit the presence data, you should use the /api/v2/analytics/users/details/query endpoint for the specific agents and timeframes. This will give you a chronological list of every presence change. You can then cross-reference this with the ‘Adherence’ records from the WFM API. I have seen cases where a small company (like the one Han77 manages) has agents stay in a ‘Meeting’ status while taking calls, which completely breaks the adherence logic!
Eli82 is right, we had this exact problem last month! It turned out that our agents were using a custom ‘Project Work’ presence that was not mapped to any activity code in WFM. The adherence engine just assumed they were ‘Unscheduled’ for the entire day. Once we mapped the custom presence to a ‘Work’ activity in the WFM Business Unit, the reports started looking much better. Always check your mappings first before diving into the API data!
I inherited our GC org six months ago and I have spent a lot of time cleaning up these WFM settings. To follow up on Han77, make sure your agents are also assigned to the correct ‘Management Unit’ and ‘Service Goal Group’. If an agent is taking calls for a queue that is not part of their WFM planning group, the adherence engine might not ‘Count’ those interactions towards their schedule. It is a complex hierarchy and it only takes one missing link to throw off your entire reporting dashboard!