Your profile, workspaces and product access¶
Your Zerohive account holds your personal details and sign-in identity. A workspace represents an organization you belong to. Selecting a workspace establishes where you are working; opening a product then depends on your membership, the organization's rules, your product access and whether that application is available in the environment.
This separation lets one person work with several organizations while keeping each organization's access distinct. Updating your personal name does not change your workspace role. Selecting another workspace does not copy documents, approvals or permissions from the previous one.
Documentation status: This is a source-backed draft awaiting domain and reader review. Profile editing and workspace selection have connected account screens. Several display and recovery limitations remain, described below. Application availability and connected workspace entry must be verified in the environment you use. These pages do not establish live deployment availability.
Use the profile and workspace guide for the current controls. Joining an organization explains how a membership begins; workspace creation covers creating and paying for a new organization.
Personal details and organization details¶
| Information | Who it belongs to | What changing it means |
|---|---|---|
| First, middle and last name | Your account | Updates the shared personal profile |
| Phone number, country and timezone | Your account | Updates personal contact or preference information; it does not change the organization's billing country or branch |
| Profile photo link | Your account | Stores a link to an image; the current form does not upload a file |
| Sign-in email | Your account | Displayed on the profile; this form does not change it |
| Membership and assigned branch | One organization | Determine whether you can enter that workspace |
| Administrator role and organization-head designation | One organization | May expose organization administration; they are separate from platform staff access |
| Product licence | Your membership in one organization | Determines the product grants associated with that membership |
| Support ID | Your account | A replaceable code used by the authorized support process |
The profile is a shared identity record, not a complete employee or personnel file. Organization-specific workforce information has a separate owner. Profile synchronization sends updates to relevant downstream services; it does not mean every product has displayed a change immediately.
Saving a profile¶
First and last names must contain text. Middle name and phone are normalized by the account service; whitespace-only optional values become absent. Country is chosen from the country catalog. A supplied country must exist, and timezone must be recognized by the running service.
The current form offers the saved timezone plus Africa/Lagos and UTC; a missing preference initially selects Africa/Lagos. The backend supports additional recognized timezone identifiers, but that does not make them available in this selector. If the country catalog cannot load, the current country is preserved and the form explains that it is unavailable.
One Save changes action sends separate changes for name, phone, timezone, country and photo link. They are not one all-or-nothing operation. A failed response can follow successful changes to other fields. Reopen the profile and inspect what was saved before retrying.
Blank phone and photo inputs are currently omitted from the save request, so clearing either visible field does not remove the saved value. The current form also has no country-clear action. An empty middle name can be saved while first and last names remain present. The task guide distinguishes these behaviors so that an apparently blank form is not mistaken for completed removal.
Workspace selection¶
Workspace Access shows memberships, account shortcuts and recoverable workspace checkouts. The current organization list includes active memberships in active or suspended organizations. A member whose branch is inactive can remain listed with access blocked. Invitations and pending join requests are separate from these memberships.
Selecting a workspace checks the current account and session, the workspace state, membership and branch access, and the organization's allowed-email policy. A workspace may therefore appear in a list but fail to open. The product chooser also checks current membership information, but still requires the workspace to exist in the saved sign-in context. Newly joined workspaces and changed access can therefore require a return to Workspace Access and selection again; a visible card is not a current access grant.
When selection succeeds, Zerohive establishes an organization-specific session and refreshes the selected organization's product information. An administrator in one workspace does not become an administrator elsewhere. Returning to Workspace Access and choosing another workspace is the supported way to change context; editing an address is not a membership grant.
The current API supplies the applied plan's name, code, trial status, expiry and commercial access state with workspace-list and selection results. An expiry countdown rounds a remaining partial day upward; zero days can mean either grace or blocked access, so the number alone does not decide entry. A free plan without an expiry has no countdown. The current frontend uses the supplied plan summary when it validates; its membership adapter does not substitute a Starter plan when information is unavailable. Complete display, failure-state and environment walkthroughs remain pending. Subscription access explains the commercial states.
Additional verification¶
An organization can require additional verification before entry. If the current sign-in has no acceptable verification record, selecting that organization sends a six-digit email code and opens Enter your 6-digit code. The code is associated with that account and workspace, expires after 30 minutes and is replaced when a new code is requested.
Verification checks account, membership and organization policy again. A correct code cannot override access that has since been removed. Send a new code repeats workspace selection, so use the newest email. Once accepted, the code is consumed and the verified sign-in is used to finish selection. Account-level extra verification and platform staff access have their own rules, described in sign-in and verification.
Product and administration choices¶
Product access has several conditions. A person needs an active account, an accessible membership, the appropriate active licence and permissions, and a product application enabled for the environment. A successful workspace selection does not certify that all product features are available.
The current chooser provides application destinations for WorkOS and HiveOrbit when enabled. Other recognized product choices are displayed as Not ready yet. An enabled backend capability, including HiveAI, does not establish a usable destination in this chooser. An application disabled in the environment displays Not available in this environment.
The current frontend keeps recognized product choices only when the selection response marks the licence active and supplies no revocation time. That checks the response used to create the workspace context; saved choices can still lag behind a later licence change. Reopen Workspace Access and select the workspace again after access changes. The organization administrator should verify the current assignment when entry is denied. Treat a card as a navigation choice, not proof of current permission.
Tenant Admin Console serves organization administrators and designated organization heads when that frontend is enabled. Platform Console is for separately authorized platform staff. Workspace ownership does not grant staff access. Platform selection checks the active staff account, extra-verification enrollment and the validity of the existing sign-in; it does not create an unrestricted administrator session.
Suspended workspaces and unfinished checkout¶
A current workspace administrator can receive a restricted recovery session when the workspace is suspended or commercial access is blocked. Ordinary members are refused that recovery session and should contact the administrator. Recovery returns no product choices or product permissions; it does not grant ordinary access to continue work.
The current API distinguishes billing recovery from an administrator-restorable pause and a restriction needing support. It returns a safe explanation for the applicable recovery category. Payment does not lift a manual or support pause, and a workspace returning to active status does not automatically restore every member or product. The inspected frontend's generic payment-recovery presentation must not be treated as the cause of every suspension. Follow workspace recovery and the organization-session explanation for the separate administrator and member limits.
Checkout recovery is a separate list of recoverable provisioning or payment work associated with the current user. It does not list every possible suspension or confer billing authority on every member. If no relevant checkout is shown, contact the organization's administrator rather than creating another workspace or assuming another payment is needed.
Support ID and personal control¶
The profile displays a ten-digit Support ID when one exists. Refresh code replaces the stored code after a successful save. The backend enforces uniqueness of stored support codes. The code participates in the authorized guided-support process, so share it only with the support person handling your request.
Refreshing a code does not call the operation that ends an existing guided-support session. The live profile does not currently provide an End guided help control, even though a separate sample component contains that label. Do not interpret a refreshed code as confirmation that an already active support session has ended.
Responsibilities and rollout decisions¶
Members maintain their own personal details and check the selected organization before working. Organization administrators resolve membership, branch, domain-policy and product-assignment issues. Authorized platform staff handle platform-account and operational support within their separate roles.
Managers and executives should assess a rollout using successful entry into the required products, not the number of visible workspace cards. A connected profile, an accepted invitation, a product licence and a deployed application are different milestones. Current display gaps, deferred frontends and missing reader acceptance remain explicit implementation constraints.
Workspace authorization PIN¶
For selected sensitive WorkOS actions, see authorization PIN setup and replacement. This is maintained for the selected workspace staff record and is separate from the account password, profile editing and workspace access. The guide identifies the intended final-screen journey and the current frontend's sample-only behavior.