> For the complete documentation index, see [llms.txt](https://docs.bloxchain.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloxchain.app/platform-guide/policies/manage-permissions.md).

# 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**)

{% hint style="info" %}
The editor's layout is being refined. This page describes what it does, not where each control sits.
{% endhint %}

## 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."

| Path tab            | Steps                                                                  | What it feels like to a member                                               |
| ------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **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

1. Pick a path tab.
2. For each step, look at **Can perform**. It lists the roles currently allowed.
3. Click **Assign role** and choose from the account's roles. You may add more than one.
4. Repeat for every step you want enabled. A step with nobody assigned shows "No role can perform this step".
5. 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:

| Status                 | Meaning                                                                                       |
| ---------------------- | --------------------------------------------------------------------------------------------- |
| **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](/platform-guide/policies/gates.md), 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](/platform-guide/policies/allowlists.md) 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](/platform-guide/operate/my-access.md) shows exactly what a given wallet can do.

## Related

* [Actions](/platform-guide/policies/actions.md)
* [Roles](/platform-guide/access/roles.md)
* [Design roles and permissions](/guides/roles-and-permissions.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bloxchain.app/platform-guide/policies/manage-permissions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.