Choosing Between User and Role Grants
Every Applications ACL grant has a principal: either one user or one role. The resource scopes and capabilities work the same for both principal types, but the maintenance impact is different.
Before you start
- After the permission mismatch is fixed, open Applications > More > Permissions. Do not use a direct route as a workaround.
- Confirm whether the access requirement belongs to a job function or to one person.
- Review the principal's current roles and existing Applications grants.
Compare principal types
| Principal | Who receives access | Best for | Ongoing maintenance |
|---|---|---|---|
| User | One selected account | Individual exceptions or short-lived assignments | The grant must be reviewed and removed directly. |
| Role | Every current member of the selected role | Stable team or job-function access | Access follows role membership. |
Use roles for repeatable access policy. Use direct user grants only when the access should not apply to everyone in an existing role.
Grant access to a user
- In Grant Access, select User.
- Enter at least two characters of the username or email address.
- Select the correct result. RAPTIX shows the selected account as a chip.
- Choose the resource scope and resources.
- Select one or more capabilities.
- Select Save Permission.
The search returns a limited list of matching accounts. Use the email address to distinguish accounts with similar names. Select the remove control on the selected-user chip if you chose the wrong account.
Grant access to a role
- In Grant Access, select Role.
- Choose one role from Select a role.
- Choose the resource scope and resources.
- Select one or more capabilities.
- Select Save Permission.
One grant can target only one role. Repeat the process if several roles need the same access.
Role access is evaluated from current role membership. Adding a user to the role makes the role's grants applicable; removing the user from the role removes that inherited path. Any direct user grants or grants from other roles continue to apply.
Review the result
The Active Grants panel labels every row as user or role. Its tabs filter by resource scope, not by principal type.
Before adding a direct user grant, check whether:
- one of the user's roles already covers the resource;
- a broader Global, Workspace, or Application grant already supplies the capability; or
- the requirement should be added to a team role instead.
Saving another grant for the same principal, resource type, and resource updates the existing row.
Recommended policy
- Grant routine team access through roles.
- Keep role scopes aligned with job responsibilities.
- Use direct user grants for documented exceptions.
- Prefer Page or Application scope for exceptions instead of broad Workspace or Global access.
- Review direct user grants during transfers and offboarding.
- Review role membership separately from the Applications ACL list; the ACL list shows the role grant, not a flattened row for every role member.
Troubleshooting
User search returns no results
Enter at least two characters and try the full email address. Confirm that the account exists in the current RAPTIX workspace.
The required role is missing
Confirm that the role exists and that it is returned by role administration. Reload the page after a role is created or renamed.
Removing a role grant did not remove a user's access
The user may have a direct grant, another role grant, an administrator role, or a broader applicable grant. Review every scope in Active Grants and the user's current role memberships.
Removing a user from a role did not remove all access
Role membership affects only grants inherited from that role. Direct grants and grants inherited from other roles remain active.