> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ofatoura.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Per-User Permission Overrides

> Grant or deny a single permission for one staff member, independent of their role, using the three-state User Permissions screen in the web admin.

Roles set the baseline of what each staff member can do. Sometimes you need a single person to do a little more or a little less than their role allows, without creating a whole new role for one exception. **User Permissions** lets you grant or deny an individual permission for one staff member, layered on top of their role.

Use this when, for example, one trusted waiter should be able to process refunds, or when a manager should keep their role but be blocked from a single sensitive action.

<Info>
  This page describes the browser dashboard. You'll find it under **Settings > User Permissions**.
</Info>

## Permissions

Only staff whose role includes the **Manage Settings** permission can open and use the User Permissions screen. Anyone without it is blocked from viewing or changing user-specific permissions.

## How overrides work

Every permission for a staff member ends up in one of three states. This is the **three-state model**:

| State                  | What it means                                                                                                |
| ---------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Granted**            | The staff member has this permission. A user-specific grant can add a permission their role doesn't include. |
| **Denied**             | The staff member is blocked from this permission, even if their role would normally allow it.                |
| **None (no override)** | No user-specific setting. The permission simply follows whatever the person's role decides.                  |

A user-specific setting always wins over the role. If there's no override, the role decides. This means you only need to set an override for the exceptions — everything else keeps following the role automatically.

<Tip>
  Prefer roles for anything that applies to a group of people. Reach for user-specific overrides only for genuine one-off exceptions, so your setup stays easy to understand.
</Tip>

## Set an override for a staff member

<Steps>
  <Step title="Open User Permissions">
    In the web admin, go to **Settings > User Permissions**.
  </Step>

  <Step title="Choose the staff member">
    Pick the person from the user selector. The list includes the staff in your restaurant (the top-level Super Admin account isn't listed here).
  </Step>

  <Step title="Find the permission">
    Browse the permission grid, which is grouped by area of the product, or use the search box to filter by permission name or module.
  </Step>

  <Step title="Grant, deny, or remove the override">
    For each permission you can:

    * **Grant** — give this person the permission regardless of their role.
    * **Deny** — block this person from the permission even if their role allows it.
    * **Remove override** — clear the user-specific setting so the permission goes back to following the role.

    Each permission shows a state badge (granted, denied, or none) and an indicator for whether the role already provides it, so you can see at a glance what you're changing.
  </Step>
</Steps>

## Reading the permission summary

The screen includes a summary panel that shows how many permissions the selected staff member effectively has, broken down into:

* **Total** — the effective number of permissions this person ends up with after role and overrides are combined.
* **Role-based** — how many come from their assigned role.
* **User-specific** — how many are set directly on this person, including both grants and denials.

This is the quickest way to confirm an override took effect and to spot people who have drifted far from their role.

## Reverting to role-based

To undo a user-specific permission and let the role take over again, choose **Remove override** for that permission. The state badge returns to **none**, and the staff member's access for that permission once again follows whatever their role allows. You can remove overrides one at a time as exceptions are no longer needed.

<Warning>
  Denials are easy to forget. If a staff member is unexpectedly blocked from something their role should allow, check User Permissions for a leftover **denied** override before changing their role.
</Warning>

## Related

<Columns cols={2}>
  <Card title="Roles and Permission Tiers" icon="users" href="/staff/roles-and-tiers">
    Build roles and apply Starter, Standard, and Advanced permission presets.
  </Card>

  <Card title="Adding Staff Members" icon="user-plus" href="/staff/adding-staff">
    Create accounts, assign branches, and pick each person's role.
  </Card>

  <Card title="Manager Override PINs" icon="key" href="/staff/manager-override-pins">
    Require a manager PIN before sensitive actions like refunds and voids.
  </Card>

  <Card title="Staff and Permissions Overview" icon="shield" href="/staff/index">
    See how staff, roles, and permissions fit together.
  </Card>
</Columns>