Why does this setting prevent WFM adherence reporting from updating correctly in our Architect flow? We are using the standard “Set Wrap-up Code” action, but the Adherence Status: Offline metric remains stuck despite agents marking calls complete. This occurs specifically for queues configured with the Europe/Paris timezone. The performance dashboard shows zero adherence for these agents during peak hours. Is there a known conflict with the wrap-up code validation logic?
Have you tried checking if the Wrap-up Code definition in the WFM module actually matches the value being set in the Architect flow? This is a super common gotcha when migrating from Zendesk where the ticket status mapping is much more flexible. In Genesys Cloud, the string literal in the “Set Wrap-up Code” action must exactly match the ID or Name of the Wrap-up Code defined in Admin > WFM > Wrap-up Codes. If there is even a single space difference, the WFM engine ignores the adherence update, leaving the agent stuck in “Offline” or “Not Adherent” states. Unlike Zendesk’s ticket fields, Genesys is extremely strict about these identifiers. You should verify the exact payload being sent by using the Developer Console or checking the flow execution logs. Ensure the wrapupCodeId in the action corresponds to a valid code in your specific WFM schedule group. Also, check that the Agent’s WFM Schedule Group is correctly assigned and active for the Europe/Paris timezone. If the schedule group is inactive or mismatched, the adherence engine will not process the wrap-up event regardless of the Architect configuration. A quick test is to manually set a wrap-up code in the Agent Desktop and see if the status updates. If it does, the issue is definitely in the Architect flow’s value mapping. Try using the exact UUID of the Wrap-up Code in the action instead of the name to avoid any localization or casing issues. This usually resolves the zero-adherence dashboard problem immediately.
Have you verified the exact string format being passed to the Set Wrap-up Code action? The WFM engine is notoriously strict about case sensitivity and trailing whitespace. When building Premium Apps that interface with these APIs, we often see that the Architect action sends a literal string, while the WFM module expects a specific UUID or a normalized name. If your flow is pulling the code from a dynamic variable, ensure it is trimmed and matched against the exact name property returned by the GET /api/v2/wfm/schedules/wrapupcodes endpoint. A mismatch here causes the adherence engine to treat the interaction as “Unknown,” resulting in the Offline status you are seeing. Debug this by logging the variable value immediately before the Set action and comparing it character-for-character with the Admin console definition.
Note: Timezone configuration in Architect does not directly influence wrap-up code validation, but it can skew the reporting window if the agent’s scheduled adherence differs from the interaction timestamp.
Check your JMeter thread group configuration. The WFM engine drops adherence updates if the API throughput exceeds the queue’s processing capacity.
429 Too Many Requests - Rate limit exceeded on /api/v2/wfm/users/adherence
Add a 500ms constant timer between requests. This stabilizes the load and allows the adherence status to sync correctly with the Europe/Paris timezone settings.