WFM Schedule Adherence Mismatch with IVR Wrap-Up Codes in Architect

Could someone explain the correct method for mapping Architect flow outcomes to specific WFM wrap-up codes when using the “Update Agent Status” action? We are seeing a significant discrepancy in our schedule adherence reports for our Chicago team (America/Chicago).

Here is the setup: We have a complex IVR flow in Genesys Cloud Architect. After a call is completed, the flow checks the disposition. If the disposition is ‘Sale’, we want the agent to automatically be placed into a specific post-call work state, let’s call it ‘Post-Sale Review’, which is configured in WFM as a wrap-up code with a 10-minute default duration. If it’s ‘No Sale’, they go to ‘Standard Wrap Up’.

We are using the “Update Agent Status” action in the Architect flow. We have mapped the “Status” to the correct WFM code ID. However, when an agent completes a call with the ‘Sale’ disposition, WFM shows them as “Available” immediately after the call ends, rather than in the ‘Post-Sale Review’ state. Consequently, their adherence drops because they are technically “not in a scheduled state” but the system thinks they are ready for the next call.

Error/Issue: WFM does not recognize the transition. The agent’s state in the WFM dashboard remains “Available” or sometimes flickers to “Unknown” before settling back to “Available”.

We are using the latest version of the Architect canvas. The WFM integration is enabled and healthy. We have verified that the wrap-up code exists in WFM and is associated with the correct team and schedule group. We are publishing schedules weekly using the WFM API, and the schedule groups are correctly linked.

Is there a specific permission or configuration in the Architect flow that we are missing? Do we need to use the WFM API directly from a script node instead of the built-in “Update Agent Status” action? We want to avoid writing custom API calls if the native action can handle this, but we are stuck. Any insights on how to ensure the IVR outcome correctly triggers the WFM wrap-up state would be greatly appreciated. We are trying to improve our shrinkage reporting accuracy.

resource “genesyscloud_architect_flow” “ivr_sale” {
…
action {
action_type = “UpdateAgentStatus”
status_id = “available” # Ensure this matches WFM skill group availability
wrapup_code_id = “sale_code_id” # Critical: Must match WFM defined code
}
}

Cause:
The discrepancy usually stems from a mismatch between the `wrapup_code_id` in the Architect flow and the actual WFM wrap-up code definition. The system requires an exact ID match. If the flow uses a legacy ID or a different code entirely, WFM records the interaction but fails to attribute it to the expected adherence metric. Additionally, ensure the agent is in a "Available" or "Available (Busy)" state before the wrap-up action triggers.

Solution:
1. Verify the `wrapup_code_id` in your Architect flow matches the ID from `GET /api/v2/wfm/users/{userId}/schedule-adherence`.
2. Check that the "Update Agent Status" action is not being skipped by conditional logic errors.
3. Confirm the skill group associated with the flow matches the one monitored in WFM.
4. Use the Genesys Cloud CLI to export current flow configs and diff against expected values. This helps identify silent failures in the deployment pipeline.