Manage Direct Permissions
Grant or revoke individual permissions for a specific member.
Direct permissions are exceptions on top of a member role. Use them sparingly so access stays easy to understand.
Roles should handle normal access. Direct permissions are for exceptions that are temporary, narrow, or specific to one member.
Every direct permission should have a reason and review date. If the access is permanent or shared by several people, create or update a role instead.
Grant Or Revoke A Direct Permission
- Open Settings.
- Go to Access Control.
- Open the Members tab.
- Select Manage for the member.
- Check or uncheck individual permissions.
- Close the dialog after the changes save.
Direct permissions appear beside the member so you can see which access was granted outside their role.
After granting access, ask the member to refresh and test the exact page or action. Do not assume sidebar visibility proves the permission works.
Before Granting An Exception
Confirm the module is enabled, the member is in the correct workspace, and their role is close to what they need. Direct permissions should adjust a narrow gap, not replace role design.
Ask what exact action the member needs to perform. Grant that permission only, then test the action. Avoid enabling broad manage permissions when the request is only for viewing, approving, exporting, or editing one area.
When To Use Direct Permissions
Use direct permissions for short-lived or narrow exceptions, such as allowing a finance reviewer to manage one extra workflow area.
If several people need the same exception, create a role instead.
Avoid using direct permissions to compensate for poorly named or overly broad roles. Fix the role design when the exception becomes normal.
Review Exceptions
Review direct permissions during access audits, role cleanup, offboarding, and team changes. Exceptions can accumulate over time and make it hard to understand why a member can access a page.
When you revoke a direct permission, ask the member to refresh the app and test the affected page. If access remains, check their base role and any other direct permission.
Offboarding and Role Changes
Review direct permissions before changing a member's role and during offboarding. Otherwise a user may keep exception access after the base role changes.
For temporary projects, remove the exception when the project ends instead of waiting for the next full access audit.
Good Practice
Record why the exception exists in your internal process. Include the owner, the reason, and the date it should be reviewed. This keeps one-off permissions from becoming permanent without review.
Permission Review Questions
Before granting or keeping an exception, ask:
- What exact action does the member need?
- How long should the exception last?
- Who owns review or removal?
- Would a role change be cleaner?
- Could the permission expose finance, HRM, files, customer messages, or settings beyond the request?
Use the answers to keep exceptions narrow and auditable.
Troubleshooting
If a permission appears granted but the user still cannot access the page, check whether the workspace module is enabled and whether the user is in the correct organization.
If a user retains access after revocation, check their role, owner/admin status, other direct permissions, and browser session state.
If a user cannot perform an action after a permission was granted, compare with a user who can perform the action and check module access, role permissions, direct permissions, record ownership, and record status.