Approvals
Anything Connect prepared under ask_before_send becomes a held action in Waiting For You, shown with the message or commitment it answers. Two decisions are available: say yes and it goes out immediately through the same send boundary a person's own send uses, or say no and the refusal is recorded against the thread. Both are written to the decision log.
What a held item looks like#
The item carries the work and its context together, so nobody has to open a second screen to judge it. Above the prepared reply sits the message being answered; beside a queued call sits the commitment it came from and when it fell due. The point is that a decision made in ten seconds should still be an informed one.
| Part | Editable | Why |
|---|---|---|
| The message or commitment being answered | No | It is the evidence, not the work |
| Subject and body of a reply | Yes | Your wording is what goes out |
| Recipients | Yes | The right people are a judgement, not a derivation |
| The mailbox it is sent from | No | Decided by the mailbox's role and the thread it belongs to |
| The rule that held it | No | It is a record of why you are being asked |
The two decisions#
Say yes.
Result The send runs straight away, through the boundary a person's own send uses — there is no second engine for approved work. The result is kept with the provider's own acknowledgement.
Watch the state after a yes.
Result Until the provider acknowledges, the state is *uncertain* rather than *sent*. A brief uncertain period is normal; a long one is a provider question, not a queue question.
Say no instead.
Result The refusal is recorded against the thread and the engine does not immediately prepare the same reply again.
If the reason should shape future work, write it down.
Result A refusal on its own is a decision about one message. A standing instruction or a memory is what turns it into a lesson.
Who decides, and what is kept about it#
Any workspace member with permission to send on that channel can decide an item on it, and the decision is recorded against the person who made it. That is what makes "who released this?" answerable months later without anyone having to remember.
The Connect Assistant can act on the queue too, within rights narrower than a person's: it can approve, send or reject a draft on request, and it cannot quote pricing or clear a do-not-contact entry whatever it is asked. Work it does is recorded as its own, not as the person's.
When the queue behaves oddly#
- It is empty and drafts are being written
- The channel is on
draft_only, which prepares and deliberately never asks. Nothing is queued because nothing is being requested. - An item will not leave after a yes
- Capacity, not permission. The decision is kept and the send waits; the item stays until it actually goes.
- An item fails the moment it is released
- The recipient is suppressed. The suppression is shown with its origin, and a do-not-contact entry is not casually cleared.
- The reply reads as though nobody was listening
- The thread moved on while the item waited. Regenerate rather than send — editing does not give the model the newer messages.
- The same item keeps coming back
- Something is re-creating the work: a follow-up falling due repeatedly, or a thread receiving fresh messages. Handle the cause on the relationship, not in the queue.
Questions#
Does the recipient see anything while an item waits?
Nothing at all. Nothing has been handed to a provider, so there is no message in flight, no delivery attempt and nothing in the sent folder. From the customer's side it is not a slow reply — it is no reply, and their clock is still running.
Can I release several items at once?
You can work through the queue quickly, but each item is decided individually and recorded individually. That is deliberate: a batch yes would be a single decision standing in for many, and the log would say so.
Is Waiting For You the same as Needs You?
No. Waiting For You holds actions requiring a yes or a no. Needs You is wider — it also carries operational problems such as a mailbox needing reconnection or a phone line in poor health, ranked together with the decisions.