Permission overrides

A permission override explicitly grants or denies one permission for one user at one node, on top of whatever the user's roles already say. Overrides win over roles.

Use overrides sparingly. They're a hatch for edge cases — a single person who needs an extra permission their team's role doesn't include, or who shouldn't have one their role does include. For anything you'd repeat across multiple people, build a custom role instead.

Opening the modal

On a member's row in the Members tab, open the action menu and pick Permission overrides (visible only if you have permission to manage roles). The modal opens for that user at the currently selected node.

The modal shows every permission in the catalogue, grouped by category, with three buttons per row:

• Default — no override. The user's effective permission state for this row comes from their roles.
• Grant — explicitly give this permission to this user, even if their roles don't include it.
• Deny — explicitly remove this permission from this user, even if their roles include it.

At the top of the modal sits the Effective permissions summary — the final computed set after roles + overrides. As you toggle, the summary updates live so you can see the result before saving.

How overrides combine with roles

When Level computes what a user can do at a given node:

1. Start with everything their roles grant (their own roles plus any propagating role from a parent).
2. Apply overrides. Grant adds a permission; Deny removes one.
3. If the same permission is overridden at multiple nodes, the closer node wins: an override at a team beats an override at the organization.
4. If the user is an Owner anywhere in the tree, they get everything regardless.

Practical implication: a Deny at a sub-team can override a Grant at the team above, but only inside that sub-team.

Why the warning

The modal shows a warning by design: "Direct permission overrides are not recommended. Overrides break role inheritance and make access audits difficult. Consider creating a custom role instead of using overrides."

The reason: a workspace where five people have ten overrides each is impossible to audit. You can no longer answer "who can manage placements on this team?" by looking at the role catalogue — you have to walk every override on every user. Roles are auditable; overrides aren't.

When to ignore the warning anyway:

• A genuinely one-off case. Sarah is on the Performance team but also helps Brand once a quarter — grant her placement-management on the Brand team via override. Building a Performance + Brand Helper role for one person is overkill.
• Time-limited expansions. Give Jen export rights for the next two weeks while the analyst is on leave. Override now, remove later.
• Locking out an outlier. Someone on a team's default role shouldn't have one specific permission. Deny via override.

Saving overrides

After toggling, click Save. Level applies the overrides immediately; the access summary updates everywhere it appears.

Overrides are per user — there's no way to batch the same override across many people in one go.

Removing overrides

Open the same modal and toggle each row back to Default. Save.

When all overrides are removed, the user's effective permissions revert to whatever their roles say.

What overrides can't do

• Grant Owner-level access. Owner is a role, not a permission. To make someone Owner, your administrator handles it through a separate flow.
• Apply to multiple users at once. Each override is for one user. To grant the same exception to a group, build a role and assign it.
• Cover multiple teams in one click. An override sits at one node; for the same exception at five teams, set five overrides (or build a propagating role).

Auditing overrides

The UI shows overrides only inside the modal — there's no top-level "list every override on this team" view. If you need that periodically, ask your administrator.