# Approvals
> Which changes wait for review: each actor's authority, controls for everyone, and reviewers, agents or people, who approve, decline, or escalate.
Some changes wait for a yes before they run. The change is held as an **approval**, and a
**reviewer** approves it, declines it, or escalates it. Nothing changes until the approval is decided.
## One principle
**Ask before what can't be undone, and report what can.** A draft, an edit, or a moved date runs at
once and shows in [Activity](/docs/concepts/activity). Issuing an invoice, sending to a customer,
moving money, and deleting wait for a yes, unless you decide otherwise.
Approvals come third, after [access](/docs/concepts/members):
1. **Access** decides whether an actor may make a change at all.
2. **Acting for** decides whose access an agent works with.
3. **Approvals** decide which allowed changes wait for a yes.
An approval never grants anything. It can only hold or refuse a change that access already allows.
## Authority and controls
Two things decide whether a change waits, and they apply to agents and people alike:
| What | Answers | Example |
| ------------- | ---------------------------------------------- | -------------------------------------------- |
| **Authority** | How much may this actor do on its own? | Continual may draft invoices, not issue them |
| **Controls** | Which changes need review, whoever makes them? | Invoices over 10,000 need review |
A change runs when it is within the actor's authority and no control holds it. Otherwise it waits as
one approval, decided the same way, whatever held it.
### Authority: how much anyone may do alone
Every actor, a person or an agent, has **authority limits**: how much it may do without review, such
as issuing invoices up to 10,000 or paying up to 5,000. Limits come with roles, as they do in a
finance team's approval matrix, and you raise them for one actor as it earns trust.
| Actor | Edits | Deletes | Finalizes | Sends | Pays | Changes access |
| --------- | ----- | ------- | --------- | ----- | ---- | -------------- |
| A member | Any | Any | Any | Any | Any | No |
| An admin | Any | Any | Any | Any | Any | Yes, reviewed |
| Continual | Any | Asks | Asks | Asks | Asks | Never |
**Coming:** authority limits as written above, set by role and raised for one actor at a time.
Today, Continual's limits are one policy every organization starts with, **Agents ask before they
commit or delete**: Continual edits freely, and asks before it finalizes a Document, sends, grants
access, or deletes anything.
### Controls: rules for everyone
A control is a rule the business keeps no matter who makes the change, a person or an agent, an
admin included. Finance adds one when you install it, **Large invoices need an admin**: issuing an
invoice over 10,000 waits for review by an admin who did not ask for it.
Changes to who may do what, such as roles, limits, and controls themselves, are always controlled,
so nobody can loosen a rule to slip a change past it.
**Coming:** controls placed on a legal entity or a team; thresholds compared in your currency; and
reviewers named by role, group, or manager, including chains such as a manager and then finance.
## Reviewers
A **reviewer** decides an approval: any actor with enough authority for the change. One rule never
changes: **whoever asked never reviews their own change**, and neither does anyone it asked for.
Today, every reviewer is a person:
- **If the rule names who approves,** someone allowed to approve where the change acts decides,
such as an admin for a large invoice.
- **If it names no one,** the person Continual worked for decides.
**Coming: agents review too.** A reviewer agent decides routine approvals up to the risk it is
trusted with, and escalates the rest: to an actor with more authority, or to more checks first, as a
wide code change gets extra testing. You choose where escalation stops, and move that line as trust
grows. An organization whose reviewers are all agents runs on its own, with nothing else changed.
### When Continual asks you
When Continual holds a change only because it lacks the authority, you are not reviewing someone
else's work: you decide whether to make it your own. **Coming:** you **adopt** the change, its card
says **Send** or **Issue**, and your own limits and every control still apply. Today you choose
**Approve**.
## Example: Continual issues an invoice
You ask Continual to bill Northstar for the confirmed order.
1. Continual drafts the invoice. Drafting is an edit, so it runs.
2. It reaches **Issue invoice**, which binds the business, so the default policy holds it.
3. Your thread shows a card for the held change, with **Decide**.
4. You choose **Decide**, check the exact change Continual would make, and choose **Approve**.
5. The invoice is issued, and Continual carries on.
## Approve or decline
The approval's to-do opens in its own thread. It shows the Action and the
exact input that would run.
Nothing changes until you choose **Approve**.
| You choose | What happens |
| ----------- | --------------------------------------------------------------------------- |
| **Approve** | The change runs as it was asked, for whoever it was asked for |
| **Decline** | The change does not run, and Continual does not try it again unless you ask |
Either way, the approval records who decided, and its to-do closes. If an approved change is refused
when it runs, for example because the record changed, the approval stays open and says why. If you
write to Continual instead of deciding, the held change is withdrawn, and Continual reads your
message.
## What an approval keeps
An approval is a record under the record it is about, so anyone who can see that record sees it. It
keeps:
- The Action and input that were asked for, and the input that ran.
- Who asked, and for whom.
- The rule that held it.
- Who decided, and a note.
An approval moves through these statuses:
## Set the rules today: policies
Today, both an agent's limits and controls are written as **policies**, in the **Policies** section
of the organization's settings, or of yours. Choose **Add policy** to create one.
| Setting | What it controls |
| ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Object** | The kind of record it governs, such as invoices; every kind when empty |
| **Operations** | The Actions it governs, by name |
| **Consequences** | Without operations, the kinds of change: **Edits**, **Deletes**, **Commits**, **Says** |
| **When** | Only records that match a filter, such as invoices over 10,000 |
| **Applies to** | **Everyone**, **People**, or **Agents** |
| **Effect** | **Require approval**, or **Deny** to refuse the change outright |
| **Approver** | The permission whoever decides must hold, such as approving requests; without one, the person an agent works for |
A policy for **Agents** sets Continual's limits; one for **Everyone** or **People** is a control.
**Commits** are changes the business is bound by. Coming: policies give way to authority limits on
roles and to controls with named reviewers.
Who may make which changes.
Decide what Continual proposes.