# Handle approvals

When an agent attempts an action that its [policy](https://docs.catena.com/policies.md) does not allow
outright, Catena will either block the action or send it to a person for
approval. For example, if Cora's Coffee's purchasing agent sends a wire to Bea's
Beans and the payment crosses a rule that asks for approval, the payment will
wait in the **Approvals** queue for an admin to approve or deny it.

## Approval requests

The **Approvals** queue in the console holds four kinds of request:

| Request                 | Raised when                                                                                                                                                                                            |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Payments                | A send, a transfer between your own accounts, or a payment to an x402 or MPP endpoint crosses a rule that asks for approval. A wallet payment that needs a signature from an approver also lands here. |
| New counterparties      | The agent tries to add a counterparty, and its policy requires approval.                                                                                                                               |
| Payment detail requests | The agent asks a counterparty for its payment details, and its policy requires approval.                                                                                                               |
| Temporary overrides     | The agent asks for a time-limited increase to one of its limits.                                                                                                                                       |

Each request has its own review page. You can reach it from the approval email,
from the Slack message, or from the link your agent gives you
(`metadata.dataUrl` on the intent).

## Approvers

Only admins can approve or deny requests. Operators and viewers cannot. We
notify admins of pending approvals by email or Slack (depending on each admin's
settings under **My notifications** in Settings). See [Team](https://docs.catena.com/team.md) for more on
roles.

## Expiry

If nobody acts on an approval request, the request will expire. An expired
payment does not happen, and the agent has to ask again. While a request is
waiting, the agent can cancel it with `catena intents cancel int_...`.

## Approval and execution

For a payment, approval is only the first of several steps. Once an admin
approves, the payment goes through the following:

1. Signing: The payment is signed. If a wallet payment needed approval, an admin
   signs it in the console, and the agent does not sign it. The sandbox has no
   passkey step, so clicking **Approve** in the **Approve payment** dialog signs
   the payment.
2. Submission: We submit the payment to the bank or the network.
3. Settlement: The payment settles or fails.

Until then, the [intent's](https://docs.catena.com/intents.md) status is `processing`. For a wallet
payment, `.movement.nextStep` on the intent shows where the payment stands.
Below are the values that `nextStep` may take:

| `nextStep` | Meaning                                                                                                                              |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `wait`     | A person is deciding, an admin is signing, or a signature is in flight. Keep polling.                                                |
| `done`     | The counterparty has been paid.                                                                                                      |
| `blocked`  | The payment has ended unpaid, and `reasons` says why. `reasons` is empty when an approval lapsed before anyone finished the payment. |

You can check where a payment stands at any time:

```sh
catena intents get int_...
```

**A payment is complete only when the intent's status is `completed`.** You can
confirm it with the linked transaction in `.data`.

## Denials

When an admin denies a request, the intent's status will become `blocked` and
its `resolution` is `denied`. The agent should accept the denial and not submit
the same request again.

## Related

- [Set policies](https://docs.catena.com/policies.md): Decide what each agent can do with its policy, from the accounts it can read and the counterparties it can pay to its spending rules and temporary overrides.
- [Intents and retries](https://docs.catena.com/intents.md): Learn how an intent moves through its statuses and resolutions, which fields explain its result, and how to retry safely with idempotency keys.
- [Team and roles](https://docs.catena.com/team.md): The three roles in a Catena organization, what each one can do, and how operators and admins divide the work.