Understand email delivery evidence¶
An email can be prepared, accepted by a delivery provider, reported as delivered, or rejected. These are different results. None proves that a person read the message or completed the work it describes.
Availability: this draft explains the inspected email processes. It does not confirm that a particular message was sent, that provider callbacks are connected in your environment, or that a delivery-history screen is available. Follow the owning feature's guide for actions in Zerohive.
Separate the message from the work¶
| Evidence | What it can mean | What it does not establish |
|---|---|---|
| A notification was requested | A process asked for a message to be prepared. | That a usable recipient was found, the category was enabled, or an email was sent. |
| A provider accepted the send | The provider accepted that attempt and supplied a reference. | Final delivery, reading, consent or completion. |
| A delivery callback was recorded | A supported provider report was matched to a tracked send. | That the recipient read or acted on the message, or that every business record was updated. |
| A failure or uncertain result was recorded | A send was rejected, bounced, or did not produce a conclusive result. | That no external send occurred, or that repeating the business action is safe. |
| The owning work record changed | The relevant feature recorded its own outcome. | That every related notification arrived. |
For example, a workflow reminder can arrive after somebody has completed the task. Read the current task before acting. A letter email can be reported as delivered while the correspondence record still needs its own delivery evidence. Use workflow deadlines and correspondence for those business rules.
Why email categories have different recovery rules¶
Ordinary service emails¶
Account, billing, invitation and other service emails generally use the common email process. It can suppress optional categories or skip a message whose sending deadline has passed. An accepted attempt can leave a reusable send result, but this is not a complete delivery history for every email.
An uncertain provider result can mean that the provider received the request even though Zerohive could not confirm it. Repeating the request can therefore produce another email. See email types, email choices and workspace notices for the category and recipient rules.
Workflow deadline alerts¶
Workflow deadline alerts have a separate dispatch record saved before contacting the email provider. Once that record shows an uncertain attempt, the same alert is not automatically sent again merely because processing repeats. A recorded rejection that is eligible for retry follows a different path.
This reduces one source of accidental repeat sends, but can leave an alert needing investigation when the provider result is unknown. A failure to receive an alert does not pause a deadline, transfer the assignment or remove the obligation. Check the current work item and its escalation history.
Official letters¶
Official-letter email dispatch tracks individual recipient addresses within a dispatch attempt. Recipients already recorded as accepted or delivered are normally skipped when that same attempt is processed again. A new dispatch attempt is different and can send to those people again.
An email-provider callback updates a notification delivery record. It does not automatically supply the letter's required delivery evidence or complete its correspondence workflow. Other channels, attachments, supporting evidence and confirmation requirements remain subject to the letter delivery guidance.
Read callback results carefully¶
A supported callback can report delivery, a temporary bounce, a permanent bounce or a feedback complaint. Its usefulness depends on reaching Zerohive, carrying a usable reference and matching an existing tracked send. A missing callback is therefore not proof of non-delivery.
Callbacks can arrive late, repeat or arrive in a different order. The workflow-alert and official-letter records apply different ordering rules. Support may need to compare the provider's event times, the saved record and the original attempt before explaining an apparent change of status.
The inspected delivery callback path ignores email-open and link-click tracking. Do not use this path as evidence that an employee read a message, accepted a decision, visited a link or met a response obligation.
Investigate a missing or uncertain email¶
- Identify the category, recipient, workspace, approximate time and original work or transaction reference.
- Check the current business record. A missing email alone does not justify a second payment, a duplicate invitation, a new letter dispatch or another workflow action.
- Check the intended mailbox and its filtering rules. For optional updates, also review your email choices.
- Preserve any displayed reference and the original attempt when contacting support. Distinguish “not received” from a visible failure or a confirmed provider report.
- Let the responsible administrator or support team establish whether the attempt was accepted, rejected, left uncertain or later reported as delivered before deciding on recovery.
There is no universal resend action established by this guide. Some repeated attempts are suppressed, some can retry, and some can send again after an uncertain result. Use the recovery process for the owning feature and tell the intended recipient when a repeat communication is necessary.
Use notification evidence in business decisions¶
Notification activity helps explain communication attempts. It is not an employee-performance measure, a universal proof of service, or proof that a legal or contractual notice requirement was met. Organizations must evaluate their own required evidence through the relevant business process.
Keep communication evidence alongside the underlying record and its current state. For urgent work, use the organization's established escalation process instead of assuming that a delivery status proves the person is aware of the issue.