Notifications and email updates¶
Zerohive uses notifications to draw attention to account changes, work that needs action and important service events. An email, an item in your Zerohive inbox and a live screen update are different ways of receiving information. They have separate settings and delivery paths.
Availability: this is a draft based on the inspected implementation and Auth and Entry final screens. Account email choices have a frontend connection to the account service. A working deployment, delivery to a real mailbox and reader acceptance have not been verified here. SMS and device push notifications are disabled in the inspected configuration and dispatch implementation.
Start with choose your email updates and understand the emails you receive. The latter covers account/security, invitation/access, work, trial/billing, usage and export messages. Workspace billing and usage notices explains recipient selection and missing/repeated-message investigation. Email delivery evidence explains acceptance, delivery callbacks and recovery across email categories. Recipients and notification data explains address changes, membership copies and workspace-data boundaries. When emails start explains the triggers, selected recipients and timing limits across all 34 formats. For conversations and attention inside WorkOS, use Messaging. The feature that produced a notification remains the place to check the current business outcome.
Understand the channels¶
| Channel | Purpose | What to expect |
|---|---|---|
| Email updates | Account/service messages and selected work updates sent to an email address. | Delivery depends on the email service and destination mailbox. A successful send request is not proof that a person received or read it. |
| Zerohive inbox | Messages and attention attached to work or conversations. | Messaging owns the inbox. Turning off an optional email category does not remove the underlying work or establish that the inbox is muted. |
| Live screen updates | Let a connected product screen refresh as information changes. | A live update is not an email or a device push notification. Reconnection and refreshed source data have separate behavior. |
| SMS | Text messages to a phone number. | Disabled in the inspected notification implementation. The presence of a phone number does not enable this channel. |
| Device push | Notifications delivered through a device's push service. | Disabled in the inspected dispatch path. Browser permission or a stored device token does not establish delivery. |
Optional email choices belong to your account¶
The inspected Email updates screens expose Leave updates and Group membership changes. These choices follow your Zerohive account across workspaces. You do not configure a separate copy for each workspace, and another person's meeting, management or administrator role does not grant control over your personal choices.
Leave updates cover emails about leave requests being submitted, their state changing and balance changes. Group membership changes cover emails when you are added to or removed from a chat group. They are not a switch for every chat message, meeting invitation or work alert.
The backend also supports a separate choice for workflow deadline/escalation emails. The inspected final screens and frontend do not expose that control. Saving the two visible choices preserves the existing workflow-alert choice. This guide therefore does not instruct you to use a third switch that is not present.
New accounts initialize these choices as enabled. A saved preference is communicated to the notification service separately from saving it in your account. An update can take time to reach the sender, and a message already being processed may still arrive. No measured propagation deadline is established here.
Important service messages remain enabled¶
The optional controls do not suppress account and security messages, invitations, billing and other service messages outside those optional categories. Official correspondence also has its own delivery process. The intended screen calls this Important messages stay on.
“Stay on” means that these optional choices do not disable those categories. It is not a guarantee of arrival, an exemption from delivery failures or proof that every possible business event generates an email. An organization should retain its normal process for urgent communications and use the source work item to confirm action.
Read the business outcome in its owning feature¶
| Notification concerns | Where to confirm what happened |
|---|---|
| A leave request or balance | Leave requests and approvals. An email does not itself approve leave. |
| A chat group or message | Messaging. Membership, message delivery and read state are distinct. |
| A meeting or saved recording | Meetings. An alert does not grant entry or prove the file can still be opened. |
| A deadline or escalation | SLA, deadlines and escalation. Read the obligation and current assigned action. |
| An official letter | Correspondence. Queuing, provider acceptance and the letter's delivery evidence are separate outcomes. |
| Account or workspace access | Account and workspace access. A notification does not create a permission grant by itself. |
What administrators and business leaders can conclude¶
Notification activity can show that a system attempted to bring something to a person's attention. It does not establish that the person read it, agreed to it, completed the task or breached a business obligation. Avoid treating send totals as productivity or response metrics.
When a user reports missing messages, identify the channel and category first. A muted optional category, a delayed preference update, a disabled channel, a rejected email and a changed source record need different responses. Ask for the approximate time and affected item; a support case should not require the user to disclose a password, security code or private recovery link.
Coverage still being completed¶
This draft covers account email choices, their global scope, generic email attempts, disabled SMS/push, all 34 supported message types, the six-signal billing/usage recipient path, and specialized delivery records and callbacks. Recipient projections, the meeting handoff, tenant export/deletion contribution and local runtime boundaries are also covered. All 34 renderer kinds now have source-traced producer triggers and recipient rules. Full upstream business-transition and cross-owner outcome reconciliation remains open. The connected environment, source refresh and initial reader walkthrough remain unaccepted.