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

# Approvals

> Where work waits, who can decide, what evidence to review, and what happens after a decision.

An approval is a decision about a proposed action or a specific reviewed quote. It is separate from permission to view or manage Agents. Do not assume that every action uses the same approval controls, or that approving always sends something.

## Where pending approvals appear

| Review surface | What to look for | Access and availability |
| - | - | - |
| The relevant workflow's pending-action panel | The proposed action, such as an email draft, and the available review buttons. | Depends on the workflow and the configured approval chain. |
| **Pricing approvals** at `/merchant/approvals/pricing` | Pricing review, quote review, the saved quote revision, and decision history. | Requires `quotes:manage` and the relevant quote-workflow availability. |
| A lesson's review record | Candidate guidance, applicability rule, cited correction, and review history. | A separate lesson-review process; not an approval to send a customer message. |

There is no single universal queue implied by this table. Open the surface for the work you are reviewing. If you cannot see a queue or decision control, check access and configuration rather than trying to bypass the review.

## Which actions require approval?

Workflow step gates and applicable action rules determine where a workflow pauses. Some steps can be configured to always require a human; protected steps cannot simply be unlocked by the reviewer. Shared rules can also apply. Availability and configuration vary by organization.

Where the approval-policy configurator is enabled, **Settings → Approvals** (`/settings/approvals`) requires `approvals:view`. Creating or managing policies requires `approvals:manage`; policies scoped to workflow steps or step actions additionally require `agents:manage`. Workflow-local gate controls have their own edit and gate-rule permission checks.

Do not change approval policy just to clear an individual pending item. First establish why the proposed action requires review and who is authorized to decide.

## Who can approve?

The configured chain and server-side authority checks determine the next eligible role or person. Having `agents:view`, `agents:manage`, or access to the pricing inbox does not by itself prove that you are the next approver for a particular item. Use the decision controls available to you; a missing control may reflect routing or an unmet prerequisite.

Some workflows require more than one signoff. Your approval can leave the item **waiting for remaining approvals** rather than completing it.

## What evidence to review

Before deciding, verify:

* The exact proposed action and its consequences: draft, send, approval, or issuance.
* The customer, recipients, order or request reference, product, quantity, units, and currency where relevant.
* The supporting source records, dates, attachments, and any conflicting evidence.
* The exact quote or PDF being reviewed, when one is available—not an earlier downloaded copy.
* The decision history and whether the item has changed since an earlier review.

An unavailable source is a reason to stop and clarify, not to approve based on the agent's confidence.

## Email actions in a workflow

A pending email action shows its draft content and supported review controls. Review the subject, body, recipients, attachments, and any quote PDF before using an explicit approve/send action. **That action can send an email.** Read the button and its confirmation rather than assuming it only records an internal decision.

Use **Edit** where supported. For multi-material quote changes, save the changes and refresh the quote review, then inspect the refreshed PDF before explicitly approving. Stale quote evidence must not be approved as though it were current.

If an **Override** control is available, read its confirmation carefully. It is not approval to send: the supported override path does not email, and it can complete Intake and allow other enabled agents to start. Do not use it as a generic substitute for rejection or correction.

## Pricing and quote decisions

The quote approval path separates **pricing approval**, **quote approval**, and **issuance**. Pricing review comes first. Issuance is a separately authorized operation after the required approvals; **quote issuance does not itself send email**.

The review panel shows the saved quote revision and, when prepared, the exact reviewed PDF. It requires a decision reason and offers **Approve**, **Send back**, or **Escalate** according to server-confirmed authority. Inspect the recorded decision history afterward.

If the quote, pricing policy, cost, or approval authority changes, the earlier review can be invalidated and a new review is required. Approval of an earlier revision is not approval of the changed quote.

## Approval, rejection, and requested changes

| Decision or state | What it means | What to do next |
| - | - | - |
| Approval with more signoffs pending | Your decision is recorded, but the chain is not complete. | Wait for the next authorized decision; do not duplicate the operation. |
| Approve/send on an email action | The approved action can send externally. | Check the resulting workflow state before trying again. |
| Quote approved | Required review may be satisfied, but issuance and any email remain separate operations. | Follow the explicitly available next operation. |
| **Send back** on a quote review | This review is returned rather than approved. | Correct the underlying issue and obtain a fresh review through the supported path. |
| **Escalate** on a quote review | The decision follows the supported escalation path. | Check the selected eligible approver and decision history; do not assume approval. |
| Rejected lesson | That candidate version is rejected, not released. | Edit as a new version and repeat review. |
| Requested correction where no dedicated button exists | A comment or conversation alone does not alter a pending action. | Use supported editing or return controls and verify the new review state. |

There is no universal **Reject** or **Request changes** button across all these surfaces. Follow the actual controls for the item. For lessons, see [the lifecycle and independent review requirements](https://docs.plastics.com/lessons/overview.md).

## Example

A quote email is ready for review. Confirm its recipients, quoted grade, quantity, terms, and attached PDF. If a price changes, refresh and inspect the new quote evidence before approval. If you are instead in the pricing inbox, approving the quote does not send that email. After any decision, verify the resulting state and whether another approver is still required.

Continue with [Workflows](https://docs.plastics.com/agents/workflows.md) or [Results and evaluations](https://docs.plastics.com/agents/results.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.