# Rejecting an action

Declining a held item stops it going out, records the decision against the thread or the commitment it came from, and stops the engine immediately preparing the same thing again. It does not teach Connect anything on its own. If the reason should shape future work, it has to be written down as guidance, a standing instruction or a memory entry.

- **Status:** Available
- **Audience:** both
- **In the app:** #/approvals, #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/rejecting/

## What happens to the work

- **Nothing is sent.** No provider was ever handed the message, so there is no recall, no retraction and nothing in the sent folder.
- **The item leaves the queue.** It is decided, not deferred; it does not come back tomorrow because nobody looked at it.
- **The record stays on the thread.** The next person to open that conversation can see a reply was prepared and turned down, and by whom.
- **The engine does not immediately re-prepare it.** A no is treated as a decision about that piece of work, not as an invitation to try a different phrasing straight away.

A declined call behaves the same way against its commitment. The number is not dialled and the follow-up carries the outcome, so the history of the relationship shows the call was considered and not made — which is materially different from a call nobody ever queued.

## Two different things called a refusal

| Kind | Who decided | What it tells you |
|---|---|---|
| A person declines a held item | A named workspace member | Judgement: this particular thing should not go out |
| A gate refuses an action | Connect, under a rule | Policy or capacity: suppression, a block, a spent limit, a provider that cannot carry it |

Both are written to the decision log, in the same shape, because a refusal is a decision and a log that only records successes cannot answer the questions people actually bring to it. When you are reading the log, the distinction above is the first thing to establish: one is a human judgement worth discussing, the other is a rule working as designed.

## Turning a no into a change

1. Decline the item.
   - Result: The immediate problem is solved: the wrong thing does not reach the customer.
2. Ask whether the same objection would apply next week.
   - Result: If it would not — a one-off, a message already answered by phone — you are finished.
3. If it would, write the reason where Connect reads it.
   - Result: Guidance on the thread affects that conversation; a standing instruction or a memory entry at the right tier affects everything that follows.
4. If the objection is that this counterpart should not be answered unattended at all, change the permission instead.
   - Result: That is a contact-scope setting, not a lesson — see [Exceptions to a rule](/docs/autonomy/exceptions/).

> **Careful** Repeatedly declining without recording why is the most expensive pattern in the queue. Each no costs a person's attention, teaches nothing, and leaves the next item looking exactly like the last.

## When the same item returns

**A new message arrived on the thread** — That is new work, not the old item. Connect is answering something the customer sent after your decision.
**A commitment falls due again** — A recurring follow-up will keep producing items until it is completed or closed. Handle it on the follow-ups screen rather than in the queue.
**Several people are prompting the same reply** — Two conversations resolving to one contact. Merging the duplicate relationship removes the double.
**It returns within minutes, unchanged** — Worth reporting. A decision that does not stick is a fault, not a configuration, and the decision log will show whether the no was recorded at all.

## Questions

### Does saying no delete the text Connect wrote?

The decision is what is kept — the record shows a reply was prepared and turned down, on that thread, by that person. Nothing is sent, and nothing about the conversation itself is removed.

### Will Connect try again with different wording?

Not straight away. A no stops the immediate re-preparation of the same work. New inbound messages or a commitment falling due later are genuinely new work and will produce a new item.

### Can the Connect Assistant decline something on my behalf?

It can act on the queue when asked, within rights narrower than a person's, and what it does is recorded as its own rather than as yours. It cannot quote pricing and cannot clear a do-not-contact entry under any instruction.

## Related

- [Approvals](https://connectbyjbrh.com/docs/autonomy/approvals/)
- [Editing before approving](https://connectbyjbrh.com/docs/autonomy/editing-before-approval/)
- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [Standing instructions](https://connectbyjbrh.com/docs/autonomy/standing-instructions/)
- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)

## What this page is based on

- Connect source pack §5 — the audit trail records refusals as well as actions (`docs-source/sources/GENERAL.md`)
- Connect source pack §7 — follow-ups and their outcomes
- Connect capability registry (`docs-source/facts.py`) — `approvals`, `audit_trail`, `followups`
- `backend/app/autonomy.py`, `backend/app/audit.py`