Blocking a sender

Why a tag and not a column#

The obvious design is contacts.blocked = true. It is also the design that breaks first, in three predictable ways: it stops a person rather than a person on a channel, it lives on one record so it has to be re-checked by every path that might send something, and it carries no reason, no author and no date.

Connect stores it where directions already live. Memory resolves narrowest-first over four tiers — workspace, channel, endpoint, contact — and directives() pulls out the ones that constrain behaviour. It reads only the tag list, never the body. So a row whose tags include block:email is a machine-readable instruction; the body of the same row is free to hold the human reason, and nothing depends on parsing it.

What one tag covers#

These are per channel because that is how the complaint usually arrives — "stop emailing me, ring me instead" is a real and reasonable request, and a single global switch cannot express it. Where the person wants nothing at all, the right record is a do-not-contact entry, described on Do not contact, which is checked in the compliance path rather than the memory path.

Because the row sits on the person rather than the thread, it survives the thread being closed, a new message arriving from them months later, and them being reached through a different mailbox.

Placing and lifting one#

1. Use the block action on the contact panel or the conversation.

   Result A connect_memory row is written against that person with the channel's tag, and the reason you type becomes the body.

2. Check it took, in the memory viewer for that person.

   Result The row is visible at the contact tier with its tag. One you cannot see in the viewer was not written.

3. To lift it, forget the row.

   Result The directive stops being returned, and they are eligible again on that channel from the next piece of work onwards.

What the other person experiences#

Nothing. There is no bounce, no automatic notice and no change to what they can send you. Their mail still arrives, is still canonicalised into a thread and is still readable. The directive governs what goes out, not what comes in — which is the behaviour you want, since the message that finally explains the misunderstanding is usually the one you would have cut yourself off from.

On your side, a thread with a blocked person shows the directive rather than quietly producing nothing, so "why has this not been answered" has an answer on the screen where the question is asked.

Questions#

Related#

• Memory in Connect
• Do not contact
• The suppression list
• Triage and priority
• Structured business memory instead of a longer prompt