Changing what Connect may do, end to end
You pick a channel, a scope and a mode, and the new rule governs the next piece of work Connect picks up. It does not release anything already waiting for a decision, it does not un-send anything already sent, and it never overrides a gate. The change is itself written to the decision log with who made it, so a widened permission is as visible afterwards as the actions it allows.
The chain#
- Trigger — a person opens What Connect May Do and changes a permission.
- User or external event — the change is the event; nothing outside the workspace has happened.
- Authentication and workspace resolution — the session resolves to one workspace, and the rule can only be written inside it.
- Ingest — the request carries the channel, the scope, the scope's subject and the new mode.
- Canonical record — the row is written or replaced in
autonomy.py's store; there is one row per channel per scope, not a history of intentions. - Reasoning — none. This stage is deliberately empty: a permission change is a person's decision, and no model participates in it.
- Knowledge, memory and rules — unchanged. Autonomy decides what may be done; memory and knowledge decide what is said.
- Autonomy and approval — the new setting takes effect for work the engine picks up after the write, resolved narrowest scope first.
- Action through a provider — nothing is sent by the change itself. Widening a permission does not flush the queue.
- Result — the next tick behaves differently; nothing retroactive happens.
- Relationship, timeline and memory — no relationship record changes; this is a workspace setting, not a fact about a person.
- Audit, usage and Needs You — the change is logged with the person who made it, and items already in Needs You stay where they are.
What the change reaches, and what it does not#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Choosing the scope | Contact, endpoint, channel or workspace | Nothing yet | Setting the workspace scope when a narrower one already exists — it still wins, and the change looks like it did nothing |
| Choosing the mode | off, draft_only, ask_before_send or autonomous | Nothing yet | Confusing draft_only with ask_before_send: the first never queues anything for a person at all |
| Saving | The rule in force on the screen | One row; the next tick reads it | A member without permission to change autonomy is refused, and the refusal is logged |
| The next tick | New work behaving under the new rule | Held actions start appearing, or stop | Widening to autonomous while a gate still applies — the gate holds and the work still waits |
| Existing queue items | The same items, unchanged | Nothing | Expecting a widened rule to release them; they were held under the old rule and stay held until decided |
| The log | One entry naming the person and the new mode | The decision log | Nothing — the change is recorded whether or not it had any visible effect |
The order a permission is resolved in#
Four scopes, resolved narrowest first: contact, then endpoint (one mailbox or one phone number), then channel, then workspace. The narrowest applicable one wins outright — it is not merged with the wider ones, and there is no averaging. Most reports of "I changed it and nothing happened" are a narrower rule quietly continuing to win.
- A contact set to
ask_before_sendkeeps asking even when the channel isautonomous. - A mailbox set to
draft_onlykeeps drafting even when the workspace isautonomous. - A channel set to
offstops that channel even when a contact setting says otherwise, becauseoffdisables the channel the narrower one lives on.
The screen shows which scope is in force for the thing you are looking at. Read that before changing anything: the fastest fix is often deleting a narrow entry somebody set months ago rather than adding a wider one.
Changing it safely#
Widen one channel at one scope, and leave the rest alone.
Result If something goes out that should not have, the cause is unambiguous.
Watch the decision log for the next few ticks rather than the outbox.
Result The log shows refusals as well as actions, so you see what the new setting permitted *and* what a gate still stopped.
If the result is wrong, narrow it back at the same scope.
Result The next tick returns to the old behaviour; nothing already sent is affected, because nothing here is retroactive.
Questions#
Does switching to autonomous send everything that is waiting?
No. Items in the queue were held under the permission that applied when they were prepared, and they stay until somebody decides them. The new mode governs work the engine picks up afterwards. If you want the waiting items gone, decide them — approving a batch is a normal way to finish a transition.
Who is allowed to change an autonomy rule?
A member with permission to change autonomy in that workspace. An attempt without it is refused and the refusal is recorded, so a permission that was tried and denied is as visible as one that was used.
Is the previous setting kept anywhere?
The store holds the setting in force, not a history of them. The history lives in the decision log, which records each change with the person who made it — that is the place to look when you need to know what the rule was in March.