Division roles not updating for WFM users

{"status": "error", "message": "The requested resource was not found", "code": "NotFound"}

i think i’m doing something wrong with the division roles. we’ve got some admins who can’t see their schedules in the UI, but the roles look correct in the user profile. it’s super annoying. i tried to push the role grant via API to see if it would force it through, but it just keeps failing.

• Genesys Cloud (Asia/Tokyo region)
• / Quality Management
• Tried calling POST /api/v2/authorization/subjects/{subjectId}/divisions/{divisionId}/roles/{roleId}
• Checked the user’s division assignments in the admin panel

i think the division ID might be the problem? i’m still kinda confused by how divisions work here. the user has the role globally, but for some reason the division-specific one won’t stick. quick one- is there a difference between the subjectId for a user versus a group when using that endpoint?

the roles are assigned, but the users are still getting “no data” when they open the views. it’s basically doing jack all for them. i tried deleting and re-adding the role using DELETE /api/v2/authorization/subjects/{subjectId}/divisions/{divisionId}/roles/{roleId} first, but the POST just won’t work.

Ran into this same wall back in '22. Thought I had the division grants locked down for a set of supervisors, but the UI just wouldn’t reflect the permissions. Spent like 3 hrs chasing my tail before realizing the issue wasn’t the role itself, but a mismatch in the subjectId.

The “NotFound” error usually means the path is wrong. If you’re using the user’s email or a nickname instead of the GUID → 404.

Try hitting the specific grant endpoint. If the bulk ones are tripping, this is the cleanest way to force it:

POST /api/v2/authorization/subjects/{subjectId}/divisions/{divisionId}/roles/{roleId}

Double check that the {subjectId} is the actual system ID from /api/v2/users. We had a case where a legacy ID was cached in our script → request hits the wrong resource → NotFound. Took a while to spot because the user profile looked fine in the admin panel, but the API call was pointing at a ghost.

Are you using the basic role grant or the bulkreplace endpoint? If you’re just hitting the standard grant, the baked-in propagation can be flaky.

I’ve seen weird sync issues where the user object doesn’t update until a session refresh. Are the admins logging out and back in, or just refreshing the page?

// Not related to roles, but here's my standard handshake for when I'm testing these things
const socket = new WebSocket('wss://api.mypurecloud.com/notifications/v2/channels');
socket.onopen = () => {
 socket.send(JSON.stringify({
 action: 'subscribe',
 topic: 'presence.events'
 }));
};

that worked! i just had them log out and back in and the schedules showed up. i think it was just a sync thing lol.

Cause: This is a classic session token lag. In Zendesk, when you change a user’s role or group, the permissions usually kick in almost instantly because the architecture is different. In Genesys Cloud, the division grant is written to the database, but the user’s active session doesn’t always pull the new permissions until they re-authenticate. It’s a known quirk that’s popped up in several other community threads.

Solution: The logout-login fix is the standard way to clear it, but if you’re doing this for a huge batch of users, you don’t want them all logging out. A better way to verify the grant actually landed without relying on the UI is to hit the subject endpoint.

GET /api/v2/authorization/subjects/{subjectId}

If the role shows up there but the user still can’t see their schedule, it’s definitely a session cache issue. For a more permanent workaround, we’ve found that using the bulkreplace endpoint helps ensure the assignment is clean.

POST /api/v2/authorization/subjects/{subjectId}/bulkreplace