# Pending approval and operator rights

> **What this chapter covers**
> Why some messages don't run immediately, what an operator is, and what you can
> do on the approval screen.

## There are two kinds of waiting

The names are close enough that this is the most common confusion.

| | [Scheduled](/guide/cn-queue) | Pending approval |
|---|---|---|
| Who is waiting | The machine, for its turn | **A person's judgement** |
| Why it stopped | The previous item hasn't finished | The sender has no run rights |
| Where | Sidebar → Agents | Sidebar → Pending approval |

## Operator rights

The idea only exists in **selectively-visible groups**.

```mermaid
graph TD
  A["Group visibility"] --> B{"Visible to everyone?"}
  B -->|"Yes"| C["Every workspace member runs immediately"]
  B -->|"No (selected)"| D{"Does this person have run rights?"}
  D -->|"Yes"| E["Runs immediately"]
  D -->|"No"| F["Goes to pending approval"]
```

Rights can be granted to a [department](/guide/cn-groups) or to a person. In the
group's grantee list, turning on **"run immediately"** makes that grantee an
operator.

> **Grant to departments.** Grant to individuals and every staff move means
> editing every group.

## What it is for

Three typical places.

| Situation | Why approval |
|---|---|
| A group with external intake (widget, email) | Unverified requests should not call tools directly |
| A group with new joiners | Let their instructions be seen for a few weeks |
| A group with irreversible tools | One person in front of sending, paying, deleting |

## The approval screen

![Pending approval](/guide-assets/cn-pending.png)

Each waiting message offers four actions.

| Action | Result |
|---|---|
| **Approve** | Runs as written |
| **Edit and approve** | Runs with your corrections |
| **Reject** | Does not run. You can leave a reason |
| **Delete** | Removes it from the record |

**The second is the one used most.** Usually the request is reasonable but the
scope is too wide or the completion condition is missing — that is something to
fix, not something to refuse.

> **Leave a reason when you reject.** Reasonless rejections repeated a few times
> and people stop asking at all — which is when that group dies.

## The settings travel with the request

A pending message does not store only the text.

```
□ which sub-agent it was headed for
□ which model
□ which tools were withheld
□ how far the drive search was scoped
```

So approving three days later runs it **under exactly the conditions the sender
intended**.

## Common misunderstandings

### "Can I require approval in a fully-visible group?"

**No.** In a fully-visible group every workspace member is an operator. If you
want an approval step, make the group **selectively visible** and narrow the run
rights.

### "Approvals pile up and nobody looks"

**There are no operators, or too few.** Approval spends human time, so a group
that will always have a queue needs operators granted at department scale. A group
where that isn't possible should **narrow its tools** instead of adding approval.

---

## Check yourself

**1. How does pending approval differ from the scheduled queue?**

<details>
<summary>Answer</summary>

**Scheduled means the machine is waiting for its turn; pending approval means a
person's judgement is required.** It happens when the sender has no run rights in
that group.
</details>

**2. Where do operator rights matter?**

<details>
<summary>Answer</summary>

**Only in selectively-visible groups.** In fully-visible groups every workspace
member can run immediately.
</details>

**3. Which action is used most, and why?**

<details>
<summary>Answer</summary>

**Edit and approve.** The request is usually reasonable but too wide or missing a
completion condition — something to fix rather than refuse.
</details>

---

Now divide the permissions up yourself. Forty minutes →
[Actually divide up the permissions](/guide/cn-try-roles)