Our workforce management team has implemented flexible scheduling for a pilot group of 30 agents. These agents have a defined shift window (for example, 08:00-18:00) but can choose their actual 8-hour working block within that window. The schedule is configured using the “Flexible” shift type in WFM.
The adherence report is generating completely unusable data for these agents. Every flexible-schedule agent shows approximately 95-100% out-of-adherence time, even when they are logged in, taking calls, and performing exactly as expected.
When I drill into the adherence timeline for a specific agent, I can see the issue: the adherence engine is comparing the agent’s actual status against the earliest possible start time in the flexible window. So if an agent’s flexible window is 08:00-18:00 and they start working at 10:00, the system marks 08:00-10:00 as out-of-adherence even though the agent was not scheduled to start until 10:00.
The WFM team configured the schedule correctly using the Flexible shift functionality. The published schedule shows the correct flexible window. But the adherence calculation does not understand flexible scheduling.
Is there a separate configuration step required to make the adherence engine respect flexible shift boundaries?
This is known limitation in current WFM adherence engine. The adherence calculation uses the schedule segment start/end times, not the flexible window boundaries. When WFM publishes a flexible schedule, it internally creates a schedule segment that spans the full flexible window (08:00-18:00 in your case) with activity type “On Queue.”
The adherence engine then compares the agent actual status against this full-window segment. If agent is not On Queue at 08:00, it marks as out of adherence.
The workaround until Genesys fixes this (there is a feature request GC-WFM-4821 open since 2024):
- Do not use the Flexible shift type for adherence-tracked agents
- Instead, have the WFM team create individual fixed schedules within the flexible window after agents declare their preferred hours
- Use a Data Action or external script to let agents “claim” their preferred time slot via a self-service portal, then programmatically update their WFM schedule via the API:
PATCH /api/v2/workforcemanagement/managementunits/{muId}/weeks/{weekDateId}/schedules/{scheduleId}
This approach gives agents flexibility while maintaining accurate adherence tracking because each agent ends up with a fixed schedule that matches their actual working hours.
We had exactly this problem when we rolled out flexible schedules for our gamification program - agents could earn flex privileges by hitting performance targets. The workaround above is solid.
For the self-service portal approach, we built a simple web app using the GC Platform SDK that lets agents submit their preferred shift start time by 6 PM the day before. A scheduled Lambda function runs at 7 PM and batch-updates all the WFM schedules via the API. This gives the WFM forecasting engine the overnight window to recalculate coverage with the confirmed shifts.
The API call to update a specific agent’s schedule is:
POST /api/v2/workforcemanagement/managementunits/{muId}/weeks/{weekDateId}/schedules/{scheduleId}/reschedule
Make sure to use the reschedule endpoint, not the update endpoint. The update endpoint requires publishing a full schedule, while reschedule allows modifying individual agent shifts.
Been dealing with WFM adherence quirks for years. Both solutions above work, but let me offer the simplest interim fix that does not require building a self-service portal.
Go to Admin > Workforce Management > Adherence Settings. There is a field called “Adherence Exception Threshold” that defaults to 0 seconds. Change this to 7200 seconds (2 hours). This tells the adherence engine to ignore out-of-adherence events shorter than 2 hours.
For your flexible schedule agents with a 10-hour window working 8-hour shifts, the maximum legitimate early/late start is 2 hours. Setting the threshold to 2 hours effectively suppresses the false out-of-adherence events without affecting the detection of genuine adherence violations (like an agent going off-queue for 3+ hours).
This is a blunt instrument and it applies org-wide, so if you have strict adherence requirements for non-flexible agents, it will mask their short violations too. But it is a 30-second configuration change that immediately fixes the reporting problem while you build the proper self-service solution.