📷 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:Add a binding
Add Binding opens a small form:
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.
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
- Approval Policies — the separate “who approves” system
- How Approvals Work Day to Day