When Zerohive starts an email¶
An email starts from a particular account, workspace or work event. It is a separate communication about that event: receiving it does not grant access, complete a payment, approve leave or prove that the underlying record still has the same state.
Availability: this draft traces the producers of all 34 supported email formats in the inspected implementation. It describes their conditions and recipients, not a verified delivery schedule or an additional product screen. Optional preferences, sending failures and mailbox delivery still affect the result. Official-letter delivery follows its own correspondence process.
Use email types to understand message contents, email choices for optional categories and delivery evidence for interpreting an attempted send. The tables below explain when a request for an email is created.
Account and security events¶
| Event | Recipient and condition | Important limit |
|---|---|---|
| A verification code is generated | The address and recipient name supplied by the account or security flow, when email delivery was selected. | The flow must supply both an address and a name. The email request carries the code's expiry as a sending deadline. Generating a code does not prove delivery. |
| A password reset is completed | The active account whose reset was completed through the inspected password-reset flow. | This confirms that reset path; do not assume every possible password-administration action produces the same email. |
| An authorization PIN is updated | The affected staff member's recorded email address. | A distinct update has its own request identity. The confirmation is separate from the code used to authorize the change. |
| A sign-in is completed | The active, verified account, after any required extra verification has completed. | The inspected flow sends a login alert for each completed sign-in. The title does not establish that an unfamiliar device was detected. |
| Extra verification is enabled or disabled | The active account after it confirms the relevant change with a valid code. | The confirmation email and the earlier verification-code email are separate messages. |
| Account reactivation is requested | The account selected by the recovery process. | The request carries the recovery challenge's expiry as a sending deadline. The recovery process, rather than the email, determines whether the link remains usable. |
| Platform staff roles are granted | A verified account when a staff-access operation changes its access; the initial administrator setup uses the same kind of notice. | An unverified account follows activation instead. The listed roles can include the requested role set, so review current authority before interpreting every listed role as newly added. |
Verification codes cover sign-in, password reset, account activation, enabling or disabling extra verification, organization entry and authorization PIN changes. They must be used only in the action that requested them. Account guides describe the actual journeys; this page adds no alternative way to bypass them.
Invitations, membership and workspace setup¶
| Event | Who is selected | What the notice does not establish |
|---|---|---|
| A workspace invitation is created | The invited person's supplied address. The message differs when account activation is required first. | An invitation is not accepted membership. Its displayed expiry is not a guarantee that the message will arrive before that expiry. |
| An invitation is accepted | The joining person receives a confirmation; eligible workspace administrators receive a summary, excluding that person's own account from the administrator selection. | A subsequent role, branch or license change can alter the access described by an earlier email. |
| Workspace activation is reported | Members whose workspace memberships are active at that point. | This selection differs from the stricter administrator selection used for commercial notices. It does not independently confirm that every recipient can enter a product now. |
| Workspace provisioning faults | The billing contact and eligible workspace administrators. | A failure notice is not a fresh check of the workspace's current recovery state. Confirm the current setup result before starting another workspace. |
| A branch is deactivated | Listed affected people with active accounts and nonblank email addresses receive individual notices. Eligible administrators outside that affected list receive a summary. | The summary count represents the listed affected people, not the number of emails delivered. |
| Expired invitations are cleaned up | Administrators with active workspace memberships, active branches, active accounts and nonblank email addresses. | The count describes the expired invitation batch, not a count of deleted accounts or delivered notices. |
The commercial recipient selection combines a valid billing-contact address, when requested, with eligible administrators and merges matching addresses. Other paths use their own recipient rules. A title such as “administrator summary” does not mean that every administrator will always receive a separate copy. See recipient details and changes.
Leave, groups and workflow deadlines¶
Leave-submission and leave-state emails go to the affected staff member. The producer needs that staff record; if it cannot find it, it creates no email. A submission notice can describe immediate approval, ordinary submission or an intervention problem. Check the leave record, including its dates and current state.
Leave-balance email is produced for a reservation, consumption, release, reversal or manual adjustment. Other ledger entries do not automatically generate this email. The producer requires both the staff member and the relevant leave policy. The effective date can be earlier than the time the communication is processed; an update is not a freshly calculated total balance.
Group-addition and group-removal emails go to the affected participant. Each membership change is identified separately, including when someone leaves and later rejoins. If the participant's details cannot be found, preparing the message fails. These messages are distinct from ordinary conversation messages and meeting invitations.
Workflow deadline and escalation alerts start from workflow obligations and milestones. The email path needs a workspace-membership copy and a resolvable recipient profile with an address. A missing prerequisite can fail preparation. The prepared destination can become older than the current profile. Use workflow deadlines and delivery evidence to distinguish the work obligation, prepared alert and delivery result.
Leave and group emails follow their optional account categories. Workflow escalation uses a separate stored preference; the inspected Email updates screens do not yet expose that control. Disabling email does not undo the work event or remove a separately produced inbox item.
Trial and subscription events¶
| Event | Recipient and trigger | Interpretation |
|---|---|---|
| Trial reminder | Eligible administrators when a configured reminder checkpoint has become due during the trial. | Checkpoints are elapsed days from the trial's start. If several were missed, the process sends the latest due reminder and records the older due checkpoints as handled after at least one request is published. It does not send a catch-up email for every missed checkpoint. |
| Trial expiry | Eligible administrators when the expiry operation applies the configured fallback plan after the trial end. | Trial expiry can proceed even when nobody is eligible to receive the email. The reported user-impact figure is calculated from the prior licensed-user count and retained capacity; check actual memberships before drawing conclusions about individuals. |
| Billing suspension | Billing contact and eligible administrators when the system suspends the subscription for its specific repeated-payment-failure condition. | Other administrative suspension reasons do not automatically produce this particular notice. |
| Billing reinstatement | Billing contact and eligible administrators when subscription renewal restores a previously suspended subscription. | An ordinary renewal of an already-active subscription does not produce this reinstatement notice. |
| Subscription cancellation | Billing contact and eligible administrators during the inspected cancellation operation, after it applies the effective plan and subscription changes. | It is not a workspace deletion notice. Missing email is not a reason to repeat cancellation without checking the subscription. |
Trial reminders also depend on a valid current plan, enabled reminder policy, an unambiguous active fallback plan and an eligible recipient. If no recipient can be used, the reminder is not recorded as sent by that process. A stored reminder checkpoint means requests were produced; it does not prove delivery to each administrator.
The following six messages follow commercial events and select the current billing contact and eligible administrators when those events are processed:
| Message | Event that starts the notification path |
|---|---|
| API usage alert | The usage service reports that usage is approaching its allowance. |
| Storage alert | The usage service reports approaching storage capacity. |
| Payment receipt | Billing reports a verified charge. |
| Payment issue | A failed-payment event supplies the attempt and suspension information. |
| Plan change confirmed | A plan-change event is received, except changes identified as subscription cancellation or trial expiry, which have specialized notices. |
| Upcoming renewal | A renewal-reminder event supplies the renewal date, amount and reminder interval. |
The notification process does not remeasure usage, verify a charge again or apply these business changes. Workspace billing and usage notices explains selection, missing notices and repeated notices. The subscription guide remains the authority for the user's available billing actions.
Export availability¶
A data-export-ready event produces email only when the current export job is found and marked ready. The selection combines the requester with current eligible workspace administrators; matching email addresses are merged for that selection. This path does not add the billing contact merely because that address receives commercial notices.
The notification carries an availability deadline and a download destination. It does not independently refresh the export, extend its retention or confirm that the recipient remains authorized to download it. A late event can still refer to an expired export. Use the authorized data-export process to establish the current result and availability; do not treat the email as a permission grant.
Delayed, missing and repeated notices¶
A displayed event date or expiry is not always a limit on when an email may be sent. The inspected security-code and account-recovery producers set explicit sending deadlines. Most other producers covered here do not, including invitations, trial reminders and export-ready notices. A delayed message can therefore describe an earlier state or an action that is no longer available.
Some producers skip an ineligible or missing recipient. Others fail when a required lookup cannot be completed. Optional preferences can suppress their own categories, and a prepared request can still fail during sending. These are different reasons for a missing email.
The system identifies communication attempts so it can recognize some repeated requests. For example, returning to the same leave state or reporting another branch deactivation can be treated as the same communication attempt. Separate group-membership changes are identified separately. None of these rules guarantees exactly one delivered message.
When investigating, retain the category, approximate time and affected workspace or work item. Check the original business outcome before repeating it. Keep verification codes, recovery tokens, private download links and unnecessary personal information out of support messages. Use notification recovery to choose the next appropriate step.