Respect Permissions, Consent, and Ownership

Before an action runs against a person, five things have to be true. Eligibility: they are in the population this workflow is for. Consent and suppression: nothing on record says do not do this. Ownership: the person running it is entitled to. Duplicate: this is not the same human under another record. Already acted: this has not already happened to them.

The temptation is to collapse those into one boolean. It is faster, it is less code, and it destroys the only thing an operator can act on, which is why the refusal happened. “Blocked” tells you nothing. “Blocked because they are suppressed” and “blocked because they are already enrolled” send you to two different places.

Consent is state, not a verdict

The previous guide established this and it belongs here as a control. A recorded request to be contacted is a consent record, and a workflow event can legitimately clear a suppression flag on that basis. Consent is state that events update in order, and the most recent statement is the one that holds.

The failure this prevents is the opposite of the one people expect. Teams worry about a system that contacts someone who opted out. The commoner failure is a system that permanently suppresses someone who asked to be contacted, because a flag got set once and nothing was ever allowed to change it.

Adding is permission. Removing is safety.

This is the most useful sentence in the pillar and it is worth reading twice.

Enrolment into a workflow is intent. It is gated, it requires permission, and it should only ever touch audiences the system owns. If somebody built their own list by hand, the system does not add people to it. That is theirs.

The sweep that removes people is not the same question at all. When someone is disqualified, or becomes a customer, or asks not to be contacted, they have to come out of every audience, including the hand-built ones the system does not manage and did not create. A suppression rule that respects ownership boundaries is not a suppression rule.

Most teams give both questions the same answer, and it is almost always wrong in one direction or the other: either the system mutates lists it has no business touching, or suppressed people keep getting contacted from lists nobody is sweeping.