Understand Zerohive¶
Zerohive brings an organization's work, people, communication, records and governed assistance into related products. Its purpose is to help people initiate work, understand their responsibilities, make authorized decisions, retain useful evidence and follow what happens next.
A team might use a request to start an approval process, a project to coordinate delivery, a case to investigate an issue, or correspondence to handle an official exchange. Documents, messages and recorded activity support those different kinds of work. HiveOrbit helps people interpret recorded contribution, while HiveAI offers assistance within the applicable access, governance and spending controls.
About this guide: This is a documentation draft assembled from the reviewed feature guides. Many product screens remain in progress, some implemented behaviors have unresolved limitations, and live availability has not been verified here. Read the linked feature's availability and recovery sections before planning operational use. A design example or documented backend capability does not establish that a working screen has been delivered.
The product and capability map leads to the detailed guides. The glossary explains unfamiliar terms.
Account, workspace and product¶
Your account is your personal sign-in identity. It includes shared profile information and account-level security. You can belong to more than one organization.
A workspace is an organization's working context. Its membership, administrators, product access, policies, commercial arrangements and work belong to that context. Your responsibilities can differ between workspaces. Selecting another workspace does not move the first organization's documents or permissions.
A product is an area of capability available through that context, such as WorkOS or HiveOrbit. Opening a product depends on current membership, the organization's effective commercial coverage and entitlement, your permissions and an available application. A previously open page or successful session can outlast a change to those conditions; it does not guarantee that a later action will still be allowed. Product access and permission to perform a particular action are separate checks.
For example, belonging to an organization does not automatically allow you to approve its requests. A management job title does not automatically grant permission to change billing or view confidential personnel information. See membership and permissions and workspace selection.
How the products relate¶
| Area | What it helps people do | Where to begin |
|---|---|---|
| Account and workspace access | Establish an account, join an organization, select a workspace and recover access | Create an account and join |
| Organization administration | Set up the workspace, manage members and branches, understand usage and commercial responsibilities | Workspace creation |
| WorkOS | Route requests and decisions, coordinate projects and cases, manage people, handle correspondence and retain records | Requests and tasks |
| Collaboration and HiveComms | Use work conversations, meetings, connected mailboxes and notifications | Messaging and the work inbox |
| HiveOrbit | Examine recorded contribution, recognition, supporting evidence and their coverage | Personal and team insights |
| HiveAI | Read permitted information, use governed knowledge and prepare supported assistance or reviewed actions | Assistance access and availability |
| Platform operations | Support customer workspaces, manage commercial operations and investigate service/lifecycle evidence | Support responsibilities |
These areas share concepts but retain their own rules. A message can discuss an approval without recording the approval. A notification can announce a change without proving that every dependent view has refreshed. A record can retain a document without establishing permission to sign it.
Choose the work structure that fits¶
A request suits work that follows a defined form and route. A published workflow determines the steps and the people or bodies responsible for them. The submitted request and its tasks have separate identities and progress.
A project organizes delivery over time. Read the project guide for its roles, planning, progress and lifecycle. Do not treat a request approval as proof that a related project has completed.
A case organizes an issue that requires investigation or coordinated handling. The case guide explains ownership, work and outcomes.
Correspondence covers memos and official letters with their own preparation, routing and decision rules. Correspondence guidance distinguishes an internal discussion from an official communication.
Records provide a governed place to organize retained information. Records and archives explains classification, access and lifecycle. Filing a document, uploading it, viewing it and signing it remain different operations.
Your organization needs to choose and configure the right process. This documentation does not assume that every organization already has the same request types, approval bodies, retention rules or project templates.
Follow a piece of work from start to outcome¶
Consider an organization that wants a repeatable internal approval process:
- Its responsible administrator or process owner defines the form, workflow and decision responsibilities through the supported configuration process.
- An authorized requester supplies the required information and submits the request.
- Assigned people review their actual tasks. They may make a permitted decision or return the request for correction.
- The requester responds to a correction within the existing request, where that action is allowed.
- A completed workflow may prepare a handoff to another business area. The receiving area's acceptance and delivery need their own confirmation.
- Authorized readers use the retained work, documents and activity to understand what occurred.
This is an example of the relationships between capabilities, not a substitute for a screen-by-screen procedure. Follow workflow authoring, request execution, approval authority and activity history for the actual rules.
People and authority¶
The people directory, organization structure, workspace membership and approval authority describe different responsibilities.
- A workforce record describes organization-specific information about a person.
- Membership establishes their relationship to a workspace.
- Product grants and permissions determine applicable access.
- Organization structure helps describe reporting and route certain work.
- Approval bodies, signing authority and delegation supply specific decision responsibilities.
Changes can take time to reach dependent work. A saved authority change does not prove that every pending task has already been reassigned. Existing decisions and historical assignments can remain relevant. Start with People and organization structure and the affected feature's authority-change guidance.
Work between organizations¶
An enterprise network can connect workspaces for defined administration and collaboration. Each workspace keeps its own identity. Linking workspaces, agreeing commercial responsibility and authorizing a particular exchange are separate decisions.
Shared work lets connected workspaces send and receive packages with defined routing, participants, decisions and documents. Acceptance, completion, filing into Records and subsequent changes have distinct meanings. Establish which organization owns the action and which information the recipient is permitted to receive.
Read enterprise networks and shared work before assuming that a network relationship grants broad access.
Documents and communication¶
Document handling supports the work around a file. An upload may need to finish processing before the file can be used. A viewer may require a fresh authorized session. Signing requires the applicable identity, authority and document state. The document guide explains these boundaries and recovery.
Communication can use conversations, meetings and connected mailboxes. Notifications draw attention to selected events through supported channels. Delivery, read status, attendance and a completed business action each need their own evidence.
Insight and assistance¶
HiveOrbit derives views from recorded work evidence and configured expectations. Initial setup separates preparing choices from enabling processing; eligibility and recovery explains why received evidence can wait, be excluded or proceed. A saved setup and a fully populated report are separate outcomes. Contribution measures, recognition points and awards answer different questions. Missing sources, current versus historical membership, incomplete processing and calculation limitations affect interpretation. Use the supporting evidence, configuration and source coverage guides before using a number in a management decision.
HiveAI combines supported assistance with the source product's access rules. An answer may include citations; an action may require review and approval. Preparing or approving an action does not by itself prove its final business outcome. Grounded answers, governed actions and workspace knowledge explain how to inspect results.
Non-private HiveAI capabilities are enabled by default in the reviewed backend, subject to licensing, permissions, governance, approved providers and spending controls. This does not establish a delivered assistant interface or provisioned provider. Private Cloud remains disabled.
Commercial and operational responsibilities¶
Workspace plans, licensed seats, product entitlements, capacity and measured usage affect access and operation. HiveAI also has its own credit and budget rules. Consult the current offered plan or contract through the authorized commercial process; this guide supplies no price list or universal trial promise.
Start with usage and capacity, subscriptions and payment and HiveAI spending. Workspace creation can require an initial verified payment before provisioning. Continued product access follows the current subscription coverage, while eligible administrators can have a separate billing recovery route. Payment, plan application and restored access should each be confirmed.
Account deactivation, workspace suspension and organization-data deletion are different lifecycle decisions. A pause in access does not imply that records have been erased. Exports and deletion have documented service, storage and retention limits. See workspace suspension and platform oversight and data lifecycle.
Read outcomes carefully¶
After an important action, inspect the returned result and reload the affected item when needed. If a response times out, establish whether the original action succeeded before creating a duplicate.
For background work, distinguish the request being accepted, work being queued, processing progressing and the final outcome being confirmed. A healthy service indicator, a recent update time or an empty list may answer only part of that question.
When seeking help, retain the workspace, item reference, action, approximate time and visible error. Share the minimum needed through the organization's support process. Organization administrators and platform staff have different powers; privileged operational recovery belongs with its authorized owner.
Continue with the capability map to find the guide for your actual task.