# 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
**Continual asks before what can't be undone, and reports 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, changing access, and deleting wait for a yes, unless your organization
decides 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 Continual's 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
**Coming.** 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 and
positions, as they do in a finance team's approval matrix, and you raise them for one actor as it
earns trust. The defaults:
| 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 |
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, changes
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, with thresholds compared in your
organization's currency.
## 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: reviewers are positions, and agents review too.** A rule names a reviewer position, such
as Treasury reviewer, held by people, Continual, or both. A reviewer decides up to its own limits and
the risk it is trusted with, and escalates the rest: up the team owners until someone's limit covers
the change, 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 decide whether to make the
change your own. Today you choose **Approve**. **Coming:** you **adopt** the change. Its card says
**Send** or **Issue**, and your own limits and every control still apply.
## 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.