Wiring in flight. User-level role assignment is operational. Group-level role assignment is partially wired — assignments take effect for tokens issued after the change, but the v1-to-v2 transition may show a brief delay (up to a minute) before existing-session refreshes reflect the new role. We expect this to tighten further this quarter.
Roles attach to users in three ways, all equivalent in effect:
From the role's side
Section titled “From the role's side”Roles & scopes → click a role → Assignments tab.
Two sub-lists: assigned users and assigned groups. Each has add / remove. Useful when the task is "I'm adding many people to this role at once" — start from the role.
From the user's side
Section titled “From the user's side”Users → click a user → Roles tab.
Lists the user's roles, directly-assigned and via-group. Add a role with the picker; remove by clicking the × on the role chip. Useful when the task is "I'm changing what this specific person can do" — start from the user.
From the group's side
Section titled “From the group's side”Roles & scopes → Groups → click a group → Roles tab.
Lists the group's role assignments. Add / remove. Useful when the task is "everyone in this group should now also have these capabilities" — start from the group.
Direct user assignment vs via group
Section titled “Direct user assignment vs via group”| Direct | Via group | |
|---|---|---|
| Granularity | One user at a time | All members at once |
| Where to look | User's Roles tab | Group's Roles tab |
| When to use | One-off, person-specific capabilities | Most cases |
Default to group-based. It scales — when someone joins or leaves the team, you change group membership in one place; the role inheritance handles the rest.
Direct assignment is for the exceptional cases: a single user with a unique capability set, or a temporary capability boost that you'll remove next week.
How long until the change is effective
Section titled “How long until the change is effective”Roles affect what's IN the access token. The token carries scopes derived from the user's roles + group memberships at the moment of token issuance.
- Newly minted tokens (next sign-in, next silent refresh) carry the new role's capabilities.
- Existing tokens already in flight carry the previous capability set until they expire — typically minutes for access tokens, days for refresh tokens.
If you need immediate revocation (the user shouldn't have access RIGHT NOW), pair the role change with session revocation:
User detail → Sessions tab → Revoke all sessions. Forces the user to re-authenticate, which mints fresh tokens with the new role's capabilities.
The user list supports multi-select + bulk-add / bulk-remove a role. Useful for "everyone in this filter should also have role X" workflows.
The audit log records bulk operations as a parent event linking individual per-user role-change events.
Common patterns
Section titled “Common patterns”"Add three new people to Operator"
Section titled “"Add three new people to Operator"”Users → multi-select the three → bulk-add → pick Operator from the picker → confirm.
"Remove a leaver from every role"
Section titled “"Remove a leaver from every role"”Sometimes the simplest thing is to disable the user (which sidesteps the issue). If you need them to still exist but with no access, open their Roles tab and remove each role; remove them from each group. Three or four clicks.
"External auditor's six-week engagement"
Section titled “"External auditor's six-week engagement"”Create the custom role once. Add them to the role on day-one of the engagement. Remove them on the last day. Don't delete the role afterward — keep it for next year's engagement.