---
key: give-a-user-a-permission-override
title: Give one person a permission their role does not have
audience: staff
section: administration/team-access
routes: ["/settings/org/rbac/overrides"]
permissions: ["rbac.overrides.read"]
features: ["settings.org.rbac"]
since: 0.0.1
updated: 0.0.1
status: published
summary: Allow or deny a single permission for one team member on top of their roles, review what they end up with, and clear the exception when it is no longer needed.
keywords: [override, exception, one-off permission, extra access, block a permission, deny, allow, per-user permission]
related: [create-a-role, change-a-team-members-roles, check-what-a-user-can-access]
---

In the sidebar, open **Administration**, then choose **User Overrides** under **Team & Access**. The page address is `/settings/org/rbac/overrides`. You can also get here from **Advanced overrides** in a person's **Edit roles** drawer on **Team & Roles**.

Roles should do almost all of the work. An override is for the odd case: the one dispatcher who also needs to approve refunds, or the one person who must not see payroll. Use it sparingly so access does not drift.

## Before you start

- Anyone whose role can read overrides can open the page. To change them, your admin has to give your role permission to write overrides.
- Know the person's roles first. If several people need the same extra access, change the role instead; see [[create-a-role]].

## Steps

1. Under **Search users**, type the person's name or email and pick them. Their **Effective roles** and a **Summary** of existing overrides load.
2. Under **Overrides editor**, use **Add override** to search the permission catalog and pick the permission.
3. Press **Allow** to grant it or **Deny** to block it, even if a role would grant it. **Clear selection** cancels.
4. Repeat for any other permissions, then press **Save overrides**.

## What you see

- **Deny wins over allow.** If a person has both, the permission is blocked.
- Under **Filter & view**, **Overrides only** lists just the exceptions you have set; press **Show all** to browse every permission and set **Allow**, **Deny** or **Clear** on any row in place.
- **Effective permissions** at the bottom is what the person ends up with once roles and overrides are combined.
- **Clear overrides** removes every exception for this person after you confirm **Clear all overrides?**.

For customer photos, choose Change your own customer-facing photo. Deny blocks self-service for a technician who otherwise has it; Allow gives it to a junior technician. View your own customer-facing photo controls viewing. These are organization permissions and do not control the person's personal profile picture. Permission to edit all team members' customer-facing profiles is broader and still authorizes an administrator to edit any member, including themselves.

## If something looks different

- **Effective roles** says a permission is required: your role cannot read effective access. You can still set overrides.
- **Save overrides** is greyed out: nothing has changed, or your role can read overrides but not write them.
- The person still cannot do the thing after an allow override: their plan may not include that feature, or a deny override is also set. Run [[check-what-a-user-can-access]] to see why.

[[route:/settings/org/rbac/overrides|Open User Overrides]]