Rule
A rule is a constraint on how Connect behaves — what it must always do, what it must never do, and where the edge of its judgement lies. Rules live on the Connect Rules screen alongside behaviour settings and the intelligence boundary. A rule narrows what Connect will do; it never widens what it is allowed to do.
Constraint, not permission#
That one sentence prevents most of the trouble here. Rules and autonomy both sound like they govern what happens, and only one of them is a gate. Autonomy decides whether an action may leave at all; a rule shapes the action if it is allowed. Writing a rule that says *send invoice replies immediately* does not grant sending — the channel's autonomy mode does that, and a channel set to hold every outbound will keep holding them.
The reverse direction is the useful one. A channel running autonomously still obeys its rules, so a rule is how you keep something out of a reply without slowing every reply down. That combination — freedom on the channel, constraint in the behaviour — is what makes autonomous work bearable to supervise.
Where rules are written#
One screen, three related things, and it helps to know which you are editing.
| What it holds | Governs | Typical entry |
|---|---|---|
| Behaviour | Tone, length, how a reply reads | Keep replies short; open with the answer |
| Rules | What must and must not happen | Never quote a price; always confirm an address before dispatch |
| The intelligence boundary | Where judgement stops and a person starts | Anything about a refund goes to a person |
Three neighbours that use the same English word#
- A mail filter
- In a mail client a *rule* moves messages into folders. Connect has triage — filters, folders, marks and schedules — and that is a different feature on a different screen. Filters decide what you look at; rules decide how Connect behaves.
- A standing instruction
- An instruction is a direction you gave, usually in words, often scoped to one contact or channel. A rule is a workspace-level constraint that applies to the behaviour itself. When a direction matters absolutely, promote it from an instruction to a rule.
- An autonomy mode
- Permission, per channel, resolved at four scopes, enforced at the send boundary before anything reaches a provider. Not a rule, and not overridable by one.
- A suppression or do-not-contact entry
- A list, not a behaviour setting. It stops contact with one recipient regardless of channel rules, and a do-not-contact entry is not cleared casually — the Assistant cannot clear one at all.
What happens when a rule bites#
It shows up rather than disappearing. A refusal is a decision, and the audit trail records what was decided, by what, under which rule, and what happened — refusals included. If a rule is quietly stopping a class of work, that is visible in the decision log rather than inferred from silence, and the item that could not proceed appears in Needs You when it needs a person.
Questions#
Can a rule let Connect send something it otherwise could not?
No. Rules only narrow. Permission comes from the channel's autonomy mode and is checked at the send boundary, so no wording in a rule widens it.
Where do I see that a rule stopped something?
In the decision log, which records refusals with the rule that produced them. That is the intended way to find out why a class of reply never appears.
Should a preference about one customer be a rule?
Usually not — that is a standing instruction or a memory scoped to that contact. Rules apply to behaviour generally, and a workspace rule written for one account will surprise you elsewhere.