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

# Role Bindings — pointing a role at specific people

> Narrow a workflow role to specific users or groups, and understand how bindings change who can act on a transition.

A workflow transition says which **role** may pull it — for example, *only a
FinanceApprover may Approve an expense*. By default any user whose roles include that
role can act. **Role bindings** let you narrow that: bind a workflow role to **specific
users or groups**, so only those people can act on that document type.

You'll find **Role Bindings** as a card **below the editor** for every document type.

> 📷 *Screenshots to be added.*

***

## When you need this (and when you don't)

You **don't** need bindings for the common case. Most organisations let role membership
do the work: give the right people the FinanceApprover role and they can approve. The
card's empty state reflects this:

> *"No bindings configured — Workflow transitions currently use permission-based
> fallback."*

You **do** want a binding when a role is broad but only certain individuals should act
on a particular document — e.g. several people hold a finance role tenant-wide, but only
two of them should be able to approve *this* document type. A binding pins the role to
those exact users.

> **Rule of thumb:** the *approval policy* decides who signs off on the **approval
> step**; role bindings constrain who can act on the **other transitions** of the path
> (submit, send, disburse, and so on). They are two different systems — a binding does
> **not** change who appears as an approver in an approval rule.

***

## The Role Bindings card

The card is titled **"Role Bindings"** — *"Map workflow roles to specific users or
groups. Without a binding, transitions fall back to permission-based access."* It lists
existing bindings in a table:

| Column        | Meaning                                                                  |
| ------------- | ------------------------------------------------------------------------ |
| **Role**      | The workflow role being pinned (drawn from this document's transitions). |
| **Type**      | Whether the principal is a **User** or a **Group**.                      |
| **Principal** | The specific user or group.                                              |
| **Priority**  | Ordering when several bindings apply.                                    |
| **Actions**   | Remove the binding.                                                      |

### Add a binding

**Add Binding** opens a small form:

| Field               | What to enter                                                                                                 |
| ------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Role**            | One of the roles used by this document type's transitions (the "System" role is excluded — it's system-only). |
| **Principal Type**  | **User** or **Group**.                                                                                        |
| **User / Group ID** | The identifier of the user or group to bind the role to.                                                      |

Save it and you'll see **"Binding created"**; remove one and you'll see
**"Binding removed"**.

***

## How a binding changes who can act

For the transition's role check at runtime:

* **No binding for that role** → the transition falls back to normal role membership:
  anyone whose roles include the transition's allowed role may act.
* **One or more bindings exist for that role** → only the bound users/groups (who also
  actually hold the role) may act. Everyone else is turned away, even if they hold the
  role.

So adding a binding *tightens* access; removing all bindings *relaxes* it back to plain
role membership.

> System-driven transitions (the locked ones with a lock icon) are never affected by
> bindings — they're fired by the system, not by a person.

***

## Related

* [The Workflow Editor](/workflows/user/the-workflow-editor)
* [Approval Policies](/workflows/user/approval-policies) — the separate "who approves" system
* [How Approvals Work Day to Day](/workflows/user/how-approvals-work)