Blocking a contact, end to end

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.

What it stops, and what it does not#

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 says it three times.

Questions#

Related#

• Block and guidance directives
• Forgetting something
• Person memory
• What Connect may do
• Relationships in Connect
• Phone and voice in Connect