Autonomy and approval
Autonomy is policy: a per-channel mode, set at one of four scopes, deciding what Connect may do without asking. An approval is an instance: one specific action held, waiting for a person to say yes or no. Approving something settles that action and changes no rule; changing the rule settles no action already waiting.
Policy and instance#
| Autonomy | Approval | |
|---|---|---|
| Is | A standing rule | One held action |
| Set at | Workspace, channel, endpoint or contact — narrowest wins | Nothing; it is produced by the rule |
| Answered by | A configuration change | A person saying yes or no, once |
| Lives on | The autonomy screen | Needs You and the approvals queue |
| Changing it affects | What happens next time | This message only |
The four modes are off (the channel is disabled), draft_only (prepare, never send, and do not even ask), ask_before_send (every outbound needs a human yes) and autonomous (act within the gates). Only one of those four produces approvals at all.
The confusion that produces a support question#
draft_only and ask_before_send look almost identical from a conversation screen and are not the same thing. ask_before_send puts the reply in front of a person. draft_only writes it and stops, on purpose — it does not even ask — so nothing appears in the approvals queue, and somebody watching that queue concludes the engine has stopped working.
The mode exists so that a workspace can watch what Connect *would* say without anybody having to keep saying no. If you are in it and waiting for something to approve, you will wait forever, and the fix is a setting rather than a ticket.
What the queue actually contains#
Needs You is not only approvals. It is the queue of decisions, approvals and operational problems for a person, ranked rather than chronological, and its entries drain by themselves as their cause clears. Voice line health escalates into it, rendered from one place for both audiences.
- An item that is a held send needs a yes or a no from you.
- An item that is an operational problem — a mailbox that stopped, a line at capacity, an allowance spent — clears when the condition does, and approving nothing is the correct response.
- Ranking exists because a held first reply to a new enquiry is a different kind of debt from a held reply on a week-old thread.
- Every decision, including a refusal, goes to the audit trail with the rule that applied.
Choosing the right lever#
- Too many approvals
- A policy problem. Move the channel to
autonomous, or narrow the caution to the contacts and endpoints that need it. - This one message must not go
- An instance problem. Reject it. The channel's rule is not the place to settle one message.
- Nothing to approve and nothing being sent
- Check for
draft_only, then foroff. Neither queues anything. - Approved and still not sent
- Not an autonomy question at all — look at the allowance, the suppression state and the send evidence. Autonomy permitted it; something else is holding it.
- Wanting a record of who released something
- The audit trail, which records the decision against the person, and the rule against the engine.
Questions#
If I change the mode, does the waiting queue empty?
Treat those as separate acts: the queue is worked item by item, and the mode governs what arrives next. If you want the held items gone, decide them; if you want fewer of them tomorrow, change the rule.
Can autonomy be different for one customer?
Yes. Four scopes — contact, endpoint, channel, workspace — and the narrowest applicable one wins. An endpoint is one mailbox or one phone number, so "everything from this address needs approval" is expressible without touching the channel.
Does approving something teach Connect anything?
An approval is a decision about one action, recorded as such. If there is a lesson in it — a phrasing to avoid, a term to use — write it as guidance or a memory. A yes and a no on their own are not instructions for next time.