> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Review & approvals
> Statuses, assignment, evidence, and approval gates — with an approval agent for the routine cases and humans for the exceptions.
Review is not a step bolted onto the end. It's where the process is actually controlled: every case arrives with its source data, what the agent did, and why — and someone decides.
Nothing critical leaves the system without an approval.
## Statuses
A case moves through a lifecycle you can filter and report on:
| Status | Meaning |
| -------------- | ------------------------------------------------------------------------------- |
| `Pending` | Queued, not yet picked up |
| `Running` | The agent is working the case |
| `Agent Done` | The agent finished; no review outcome yet |
| `Needs review` | Flagged — by the agent, an approval agent, or a human — and waiting on a person |
| `Approved` | Reviewed and accepted |
| `Rejected` | Reviewed and refused |
| `Error` | The run failed |
| `Archived` | Closed out and hidden from the working views |
`Needs review` is the interesting one. It is not a failure state — it's the agent declining to decide something it can't decide safely. See [honest uncertainty](#honest-uncertainty) below.
## Assignment
Cases can be assigned to people, so a queue is a queue and not a shared mailbox nobody owns.
* **Assign** a case to a reviewer.
* **Assigned to me** — a reviewer's working list.
* **Unassigned** — everything nobody has picked up. Filter on it so cases don't sit unclaimed.
Combine with status filters for the views your team actually works from: *Needs review · Unassigned* is where a controller starts their morning.
## What a case shows
Open a case and you get the evidence, not a verdict:
* **Source document** — the original file, alongside the result.
* **Input data** — what came in: the payload, the file references, the trigger.
* **Output fields** — the structured result the agent produced.
* **Reasoning** — what the agent concluded and why, in its own words.
* **The actions taken** — the queries it ran, the files it read and wrote, the emails it drafted.
* **References** — the master-data records it matched against, so you can check the match rather than trust it.
A reviewer's job is to check the reasoning against the source, not to redo the work.
## Comments
Reviewers comment on a case — with @-mentions to pull in a colleague and attachments where they help.
Comments aren't just a paper trail. **The agent reads them.** A rejection that names the rule ("we never ship express to AT") becomes something the agent can apply and, later, propose as an SOP change through [the improvement loop](/concepts/improvement-loop).
## Approval gates
Some actions wait for a human by design:
* **Outbound communication** — an email the agent drafted is a draft until someone approves it.
* **Critical pushes** — writing a result back into a connected system of record.
The agent does the work up to the gate: the reply is written, the fields are filled, the case is ready. A person's decision is the last step, not the whole job.
Your ERP stays the system of record. Nothing posts, pays, or leaves without an approval.
## Agentic approval mode
Once a process is stable, having a person confirm every clean case stops being control and starts being throughput cost. Turn on **Auto Review** on the reconcile table and a second agent — an approval agent — checks each result before it reaches a human.
It sees the agent's output and its reasoning, checks them against the [SOP](/concepts/sops), and looks for duplicates already in the table. Then it decides:
| Decision | When |
| ---------------- | ----------------------------------------------------------------------------------------------------- |
| **Approved** | The agent was confident, nothing was flagged, no duplicates — the case can continue |
| **Needs review** | The agent flagged uncertainty, escalated, hit a conflict, or a duplicate was found — a human takes it |
| **Rejected** | The output is unusable — broken or nonsensical values — and the case is blocked |
It defaults to `Needs review` when it isn't sure, and attaches a one-line comment saying why. You keep the exceptions; it clears the routine.
Turn Auto Review on after you've reviewed a few hundred cases by hand and your SOP reflects what you learned. Enabling it on a young process just automates an unfinished procedure.
## Honest uncertainty
When the agent can't resolve something safely, it says so and shows its work:
> Two candidate customers match "Meridian Handels" at postal code 8010 — customer 40118 (Meridian Handels GmbH, Ostbahnstrasse 14) and customer 40233 (Meridian Handels GmbH, Ostbahnstrasse 14a). The order carries no VAT ID or contact email to distinguish them. Flagged with both candidates.
That case gets `Needs review` with the candidates listed. No customer number was invented.
This is the system working. An agent that guesses to keep its automation rate up is worse than useless in a finance process — the wrong answer costs more than the missing one. Cases that stay flagged are telling you where your procedure is genuinely ambiguous, which is exactly the input the [improvement loop](/concepts/improvement-loop) needs.
Turning review feedback into a better SOP.
Grants, gates, audit trail, and data residency.
Where stop-and-escalate rules are written.
The Auto Review toggle and the rest of a reconcile table's configuration.