Staging draft Work in progress · For review; coverage and acceptance incomplete

Understand recipients and notification data

Different notifications choose their recipients at different points in a business process. Updating an account, leaving a workspace or changing an email preference does not rewrite every message that is already being processed.

Availability: this draft describes the inspected recipient and data-lifecycle behavior. It does not confirm a particular workspace's synchronization, export or deletion result. It introduces no new account-settings or data-removal screen.

Where recipient details come from

Notification path How the destination is chosen What to consider when details change
Ordinary service email The producing process supplies the recipient address and name when it requests the email. The later sender does not automatically replace that destination with the latest profile.
Workflow deadline alert The notification service uses its workspace-membership and profile copies; it can request a profile when no local profile exists. An existing local profile may still be waiting for an update. The prepared email keeps its selected destination.
Workspace billing and usage notice The bridge requests the current billing contact and eligible administrators during processing. The recipient list may differ from the list that existed when the business event occurred. See workspace notices.
Official-letter email The dispatch request supplies the recipient information for that execution. Correcting a person's details does not rewrite the previous execution or prove that a new attempt is needed. See correspondence.

An email address that passes a format check is not evidence that the mailbox belongs to the intended person, is monitored, or can receive a message. A message addressed to someone is also not a permission grant. Opening the linked work still depends on the owning feature's current access rules.

After a profile or membership change

The account service distributes profile and workspace-membership changes to notification services separately. Those updates can arrive after the account change has been saved. There is no measured synchronization deadline established by this documentation.

Use your profile and workspaces for the account record and membership and access for the workspace relationship. If messages continue to use old information, preserve the message category and approximate time so support can distinguish an already-prepared email from a delayed profile or membership update.

A membership removal removes the notification service's membership copy when that change is processed. It is not an email recall, and it does not erase every historical delivery record or the person's global account profile. A late or repeated synchronization message can also require investigation. Do not infer current access from a message addressed to a former member.

Account deactivation and recovery and workspace suspension are separate processes. Disabling an account, pausing a workspace, leaving a workspace and deleting workspace data should not be treated as interchangeable actions.

What information the notification service keeps

The service maintains a global profile copy containing the user's name, email, optional phone details and picture reference, plus a lifecycle version used to order profile updates. It also maintains account-wide email preferences. A phone number in that copy does not enable SMS, which is disabled in the inspected implementation.

Workspace-specific information includes the user's workspace relationship and name of the workspace. Specialized email records can include recipient addresses, provider and dispatch references, delivery status, failure details and event times. Delivery evidence explains what those records can and cannot prove.

These operational records need access protection. Public documentation does not expose actual recipient details, message contents or provider references from a live workspace.

Workspace export and deletion boundaries

The inspected workspace export includes the notification service's official-letter delivery records, workflow deadline-email records and workspace-membership copies. The matching deletion contribution removes those same tenant-owned records. This describes the notification service's part of a larger data operation, not a complete platform export or proof that deletion has finished everywhere.

The global profile copy and account-wide email preferences are outside this tenant-data contribution. Removing one workspace's data is not a global account-erasure operation. Follow the approved account or workspace data process to establish the actual scope, result and any retained information.

An export or deletion of local notification records does not recall email already delivered to a mailbox, delete copies held by an external provider, or erase a recipient's downloaded copies. No automatic retention period or provider-erasure guarantee is established by this guide.

Ask for help with the original context

Provide the affected workspace, notification category, approximate time and original work or data-operation reference through the approved support process. Explain whether the concern is an old address, a former member, a repeated message, missing delivery or an export/deletion result.

Support must compare the current account or membership record, the synchronization state, the recipient selected for that request and any retained delivery evidence. Correcting one record does not prove that all four have changed. Use the owning business record to determine what action remains necessary.

Zerohive documentationStaging draft · 22 Oct 2026

Search documentation

Search guides, platform concepts and tasks.

↑ ↓ to move Esc to close