Approval on a follow-up

A follow-up is executed through its channel's ordinary gates, so the autonomy rule governing that channel decides whether the action leaves or waits for a person. On the phone drain a held row's outcome is recorded literally as "awaiting approval". A rejection ends that attempt and leaves the commitment open — it does not decide the commitment is gone.

Status: Available What this means
Audience: both
In the app: #/needs-you, #/follow-ups
Last verified: 2026-09-10
Product version: 6.3.2

There is no separate follow-up autonomy#

This is the part worth getting straight first. A follow-up does not carry its own permission to act. When the row comes due, the drain attempts the action through the channel, and the channel's autonomy rule applies exactly as it would to a reply somebody was writing at that moment. If replies on that channel need approval, so does this.

The practical consequence: tightening autonomy on a channel tightens every follow-up on it, including ones scheduled before the change. That is usually what people want and occasionally a surprise, so it is worth knowing which way round it works.

What the approver sees#

The reason. Which is why a thin reason costs somebody else time — the approver was not on the call.
The person, and what is already owed to them. The relationship's open commitments are the context for whether one more contact is right.
The action itself. On a message channel, the words that would go out. On the phone channel, the call that would be placed and the line it would go out on.
When it was promised for. A row being approved four hours late is a different decision from one being approved on time.

The item is ranked in Needs You with everything else waiting on a person, rather than sitting in a queue of its own. That is deliberate: a held call-back to a customer who has been waiting since yesterday and a held reply on a first enquiry are the same kind of debt, and separating them into two screens makes them impossible to judge against each other.

The three outcomes of an attempt#

Recorded as	Meaning	What to do
`call placed <id>`	The call went out and has an identifier you can follow	Nothing — the attempt succeeded and the call has its own record
`awaiting approval <id>`	The action is held for a person	Approve or reject it in Needs You
`refused: <reason>`	A gate stopped it, and the reason says which	Read the reason: some clear themselves, some need you

"Awaiting approval" and "refused" are not the same thing and are worth telling apart at a glance. An approval is waiting for a decision that only a person can make. A refusal has already been decided — by a budget, a suppression, a line that is not ready — and approving is not one of the available answers.

What a rejection does#

Reject the held action in Needs You.
Result That attempt ends. Nothing goes out, the customer sees nothing, and the decision is recorded against the person who made it.
Decide what happens to the commitment itself.
Result The row is still open and still owed. A rejection is a judgement about this attempt, not a conclusion that the promise was wrong.
If the commitment should not be kept at all, cancel the row — or use stop_for_person if the whole relationship should go quiet.
Result The queue stops offering it, and nobody re-approves it next week by mistake.
If it should be kept later, move the due time.
Result It comes back when it is right, rather than at the next tick.

Questions#

Can I require approval for follow-ups but not for ordinary replies?

Not as a follow-up setting, because there is no follow-up-specific autonomy. What you can do is narrow the scope of the channel's rule — autonomy resolves at more than one scope and the narrowest wins, so a rule against one contact or one mailbox is the usual way to tighten a subset.

Who is allowed to approve one?

Anyone with permission to act on that channel in that workspace. The approval is recorded against the person, which is what makes 'who released this' answerable months later.

Nothing is in Needs You but the follow-up did not fire.

Then it was refused rather than held. Look at the row's recorded outcome: a refused: reason names the gate, and the fix is that gate rather than an approval.