Manage permissions
Decide which role may perform each step of an action, on each execution path the action supports.
Where: Policies → Actions → action drawer → Manage permissions (also Roles → role drawer → Manage role permissions)
What you are editing
An action can run on up to three execution paths, and each path is a sequence of steps. The editor lets you name, per step, the roles that may perform it. Its heading says it plainly: "Control who can perform each step of this operation."
Delayed release
Request → wait → Approve (or Cancel) → executes
Wallet in New request; approve on-chain in Approvals after the time lock
Signed approval
Request → Sign approval (or Sign cancellation) → broadcaster finalises
Wallet to request, Sign to approve
One signature
Sign and approve request → broadcaster finalises
Sign in New request; no separate approval
Within each path the steps are grouped as Request, Approval and Execute. Cancel steps appear as an Alternative action under Approval: they end the request instead of advancing it.
Assign a role to a step
Pick a path tab.
For each step, look at Can perform. It lists the roles currently allowed.
Click Assign role and choose from the account's roles. You may add more than one.
Repeat for every step you want enabled. A step with nobody assigned shows "No role can perform this step".
Review your draft, then sign. Reset discards unsaved draft changes.
Changes are drafted locally until you sign; the on-chain state is untouched. The signed batch is then submitted by a broadcaster and shows up in Approvals meanwhile.
Path status
Each path tab carries a status so you can see what a member will experience:
Ready
Every step on this path has at least one role
Missing permission
A required step has no role. The path cannot complete.
Not enabled
The action does not support this path. Nothing to configure.
Partial capability
Some steps are staffed, so the path can start but not finish, or finish only via another path
Custom
A configuration that does not match a standard pattern; check each step
After you sign
Assigning a permission creates a need for a gate. Go to Gates, where the new rows appear under Needs attention, and grant them. Until you do, the action shows Gates mismatch and members are denied. Then check the Allowlists for the destinations the action needs.
Design recommendations
Separate requester and approver. Give Request to an Operator role and Approval to a different role. A single key should not be able to both propose and clear a payment.
Keep Owner as a fallback approver, so a stuck request can always be cancelled or approved, but do not make Owner the everyday requester.
Least privilege. Enable only the paths you use. If nobody needs One signature on a transfer, leave it unstaffed; it is the path with no waiting period.
Execute belongs to broadcasters. Finalise steps usually go to Broadcaster. That role only submits what others have signed.
Mind permanent grants. Steps marked permanent can only be withdrawn by deleting the role.
Test with a member after each change. My access shows exactly what a given wallet can do.
Related
Last updated
Was this helpful?