Association Communication
What It Is
An association communication spans a workflow's request and the messages produced for individual recipients. It carries the association's e-mail to members or contacts rather than organizing staff inbox work. The request explains the workflow intent; each message explains rendering, withholding, submission and the provider's later reports.
Protection and capacity belong to this same outcome. A communication cannot be understood only as a body handed to a mail provider. The sender needs to be usable, recipients must pass policy, retries must respect uncertain submissions, and Marketing traffic must not consume the transactional lane's reserved capacity. These are facets of the communication rather than another independent product concept.
What It Is Not
A request receipt is not provider acceptance, and provider acceptance is not evidence of a person reading an e-mail. Dispatch, delivery and engagement remain separate facts. A transactional purpose can ignore general contact opt-out while still respecting address suppression and environment protection.
How It Is Used
A macroservice stores request content and inserts its queue pointer in the business transaction. Processing pins the appropriate content and creates one message identity per recipient. Final pre-send checks can still withhold or expire accepted work. Provider feedback updates message history asynchronously. Staff inspect outcomes through read permissions, while body access requires an additional sensitive permission.
Its Facets
Submission. The request identifies purpose, template owner or version, source records, recipients and idempotency key. Link workflow submission to durable message history.
Acceptance decision. Accepted, configuration-blocked, suppressed and invalid outcomes retain reasons. Explain why a submission produced mail or stopped.
Object and queue pointer. Request objects have a thirty-day lifecycle; committed queue pointers make them dispatchable. Keep large content out of queue entries and relational rows.
Recipient message. A rendered message retains rendering kind, pinned version, dispatch state and provider delivery state. Trace the distinct outcomes for each recipient.
Withholding explanation. Suppression, reserved domains and environment policy explain protected recipients. Distinguish deliberate withholding from processing failure.
Submission attempt. Each provider handoff has an attempt record and result. Investigate retries and ambiguous submissions without promising exactly-once delivery.
Provider feedback. Send, delivery, deferral, bounce, complaint, rejection, open and click reports are deduplicated. Record provider outcomes separately from dispatch.
Activity signals. Open and click counters distinguish automated activity from likely-human signals. Show engagement without equating it with confirmed reading.
Traffic classification. The purpose selects transactional or Marketing delivery; Marketing includes subscription and unsubscribe metadata. Reserve transactional capacity and support unsubscribe headers.
Documents and copies. Caller-rendered messages can carry bounded attachments and optional copy addresses. Send workflow documents while checking copies like recipients.
Address suppression. Permanent bounce, complaint or staff action creates a workspace do-not-send entry released only with a reason. Protect recipients and sender reputation.
Demonstration addressing. Reserved domains cannot receive delivery in any environment. Prevent sample addresses from becoming provider sends.
Nonproduction policy. Test mailboxes and explicitly permitted addresses or domains are the only nonproduction destinations. Constrain test delivery without claiming that all permitted recipients are synthetic.
Association sender. A workspace setting records address or domain strategy, DNS instructions and provider verification. Use association identity when it can send.
Fallback address. Rhythm's shared sender remains available until workspace identity is verified. Continue eligible delivery while DNS verification is pending.
Account capacity. Separate lane rate budgets and a Marketing quota pause reserve capacity for transactional traffic. Control bulk sending without guaranteeing workspace fairness.
Feedback correlation. Provider configuration and message tags identify the workspace and message in reports. Associate asynchronous feedback with retained history.
How It Relates
Platform-rendered communications pin association template versions; caller-rendered purposes use supplied content instead. Notification submissions share the idea of durable queue publication but serve staff inbox outcomes. Recipient protection and sender verification remain communication facets, which is why the former safeguards concept is superseded.
What It Could Become
The product should agree on ambiguous-submission recovery, fair workspace capacity and the ownership of adopted sender identities. It should also confirm the later caller-rendered and Marketing extensions and define retention maintenance. Design must keep provider signals distinct from promises about human receipt or reading.