Capture a person’s communication choices
Purpose
A person's reachable address does not explain how that person wants communications handled. This capability stores contact-wide restrictions and per-communication-type choices, giving staff a place to record the member's instructions alongside the identity. It deliberately separates storing a preference from the responsibility of a sender to apply it.
How It Works
Contacts carry broad do-not-mail, do-not-call, and e-mail-opt-out flags, initially false. They can also carry a preference entry for each communication type, with an enabled choice, subscription status, and optional subscription e-mail address. Supplied addresses use canonical valid e-mail values, and repeated communication types refuse the aggregate at the duplicate entry.
Today the service accepts a communication type identifier without establishing that it belongs to a recognized catalogue. The stored status distinguishes subscribed, digest, and unsubscribed. Staff retrieve the saved preferences with the contact, but this milestone does not establish how every message sender interprets or enforces those choices.
Example
A membership coordinator records Ruth's request not to receive postal mail and stores a newsletter preference with digest status and her chosen subscription address. Reading the contact later shows both the general restriction and the specific subscription choice. This demonstrates persistent instructions; it does not demonstrate that a newsletter is delivered as a digest or that a postal campaign excludes Ruth.
Ruth uses ruth.kim@example.org for the newsletter and keeps a different address in her ordinary contact e-mail collection. The coordinator records that subscription destination explicitly. If she accidentally submits a second preference for the same newsletter with a competing enabled choice, the save identifies the repeated entry instead of choosing one of the two instructions. She corrects the submitted preferences and reads the contact again to check the saved result.
A later request to unsubscribe is a change to the stored instruction. Staff can inspect the unsubscribed status, but should verify any mailing outcome through the sender's own contract. In the same way, a digest status describes the saved choice here; it is not evidence of a digest schedule or a successful send. The capability test specification separates persistence and validation from those unestablished delivery outcomes.
Why It Works This Way
Our reading is that broad channel restrictions and per-type preferences express different member instructions, so neither can safely substitute for the other. A single entry per communication type avoids competing settings for the same subscription. Canonical addresses prevent superficial spelling differences from changing the meaning of a stored destination.
The sender boundary matters because a reliable storage operation cannot prove a downstream campaign respects the choice. Acceptance of unrecognized communication types is current behavior, not proof of a product decision about catalogue authority. Keeping that uncertainty explicit prevents future engineers from assuming a validated subscription catalogue already exists.
The enabled choice and subscription status remain distinct stored properties. A reader must not infer a universal precedence rule between them or between a subscription and the broad channel flags: the capability establishes their storage, while the sender's interpretation is outside the milestone. This is a boundary for future changes as well as for staff expectations.
Relationships
Establish a person’s CRM record and Save corrections without overwriting another change persist these preferences with the contact. Maintain reliable contact points owns the person's ordinary e-mail collection, which differs from a subscription-specific address. Platform communications owns message sending; compliance notices have their own recipient selection contract and must not inherit unspecified preference behavior from this capability.