# Blocking a contact, end to end

Blocking somebody is one memory row against the contact, tagged `block:<channel>`. From the next piece of work Connect will not initiate or reply on the channels the tag names, on any path — including a call placed from a colleague's browser. Their messages still reach you, which is deliberate: a block controls what the business sends, not what it receives.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/calls
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/blocking-someone/

## The stages

1. TRIGGER — somebody asks not to be contacted, or a colleague decides the business should stop
2. USER / EXTERNAL EVENT — a person opens the contact and, from it, the memory viewer
3. AUTH / WORKSPACE RESOLUTION — the session resolves to one workspace; the row will belong to it and to no other
4. INGEST / REQUEST — the tag is added from the viewer, the memory sheet in the grid, or by asking the Connect Assistant
5. CANONICAL RECORD — a `connect_memory` row against the contact, `block:<channel>` in the tag list and not in the body
6. CLASSIFICATION / RESEARCH / REASONING — the next piece of work is triaged normally; a block is not a filter on inbound
7. KNOWLEDGE + MEMORY + RULES — `directives()` reads the tag list and returns the block
8. AUTONOMY / APPROVAL — independent of the channel's autonomy mode; an autonomous channel is blocked just as firmly as one that asks first
9. ACTION / PROVIDER — the outbound path refuses. On the phone that is `comms_providers.dispatch_call`, where memory blocks, consent, autonomy and budget all gate the attempt
10. RESULT — nothing is sent, and the refusal is an outcome rather than an error
11. RELATIONSHIP / TIMELINE / MEMORY — inbound from that person still arrives, is recorded and is visible on their timeline
12. AUDIT / USAGE / NEEDS YOU — the refusal is recorded, because a refusal is a decision

## Doing it

1. Open the contact and add the block as a tag on a memory row, naming each channel it covers.
   - Result: It is in force from the next piece of work. Nothing needs approving and nothing is queued.
2. Write the reason in the body of the same row.
   - Result: The body has no effect on behaviour — the tag is what is read — but the next person to look at this contact learns why, instead of guessing or reversing it.
3. Check whether a suppression or do-not-contact entry is also warranted.
   - Result: A block is about a person and is easy to lift; a suppression is a protection recorded against an address, with its origin, and is deliberately harder to undo. A formal opt-out deserves both.

> **Careful** Deleting the row is unblocking. If somebody later tidies the contact's memory and removes what looks like an old note, contact resumes on the next piece of work. Writing the reason in the body is the cheapest guard against that.

## What it stops, and what it does not

| Situation | Blocked? | Why |
|---|---|---|
| Connect drafting and sending a reply on a named channel | Yes | The outbound path checks directives regardless of autonomy mode |
| An outbound call placed by the follow-up drain | Yes | `chase_phone` places calls through the same gates as any other outbound |
| A colleague dialling from the browser softphone | Yes | A browser call goes through `dispatch_call` with a `placer`, so it meets the same checks |
| The person emailing or ringing in | No | Inbound arrives and is recorded — you generally want to know they tried |
| A different person at the same company | No | A block is against a contact, not an organisation |
| Another channel the tag does not name | No | The tag names its channels; blocking voice does not block email |

The last two are the ones to check when a block seems not to have worked. Most often it did work, on the channel and person it names, and the message that went out was to a colleague of theirs or on a channel the tag left open.

## Why a tag rather than a field

A boolean column on the contact would have been simpler to write and worse in three ways. It would need a second column per channel; it would sit in a screen separate from everything else known about the person; and it would have no natural place to record why. As a tagged memory row it holds across channels and across future conversations, appears in the viewer beside the rest of the contact tier, and carries its own explanation.

The trade is that the tag is load-bearing and the prose is not. Anyone editing a block has to understand that, which is why [block and guidance directives](/docs/memory/directives/) says it three times.

## Questions

### Does a blocked contact know they are blocked?

Nothing is sent to tell them, and nothing changes on their side except that replies stop. Their inbound messages and calls still arrive at the business. If somebody asked to stop being contacted, that is the behaviour they asked for; if the block was a mistake, their next message is how you find out.

### Can I block every channel at once?

Name each channel the block covers on the row. There is no separate global switch, and that is deliberate — most real requests are about one channel, and a person who asks you to stop ringing usually still wants the invoice.

### Who can lift a block?

Anyone in the workspace who can edit the contact's memory, by removing or changing the tag. A formal do-not-contact entry is a different mechanism and is not cleared casually — the Connect Assistant cannot clear one at all, and its refusal is recorded.

## Related

- [Block and guidance directives](https://connectbyjbrh.com/docs/memory/directives/)
- [Forgetting something](https://connectbyjbrh.com/docs/memory/deleting/)
- [Person memory](https://connectbyjbrh.com/docs/memory/person-memory/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Phone and voice in Connect](https://connectbyjbrh.com/docs/phone/)

## What this page is based on

- docs-source/sources/GENERAL.md §3 — blocking is a tagged memory row, not a column
- docs-source/sources/GENERAL.md §6 — directives() reads only the tag list
- docs-source/sources/PHONE.md §3 — dispatch_call with a placer gates every outbound call
- docs-source/sources/PHONE.md §11 — the softphone's outbound path