Create an account and join an organization¶
Zerohive separates your personal sign-in account from your membership of an organization. You create and verify one account, then use an invitation or an approved request to join a workspace. The same account can belong to several organizations. Each organization controls your membership, role and access to its products.
This distinction matters when onboarding employees or collaborators. An email address on file is not proof of workspace membership. An invitation reserves capacity but does not let its recipient start work. A request asks an administrator to approve access; it does not approve itself.
Documentation status: This is a source-backed draft awaiting domain and reader review. Registration, activation, invitation decisions and join-request submission have connected account screens. The organization-administration invitation and join-review screens currently use sample data and local changes. Their displayed success is not a completed server action. No live deployment or email-delivery walkthrough is claimed here.
Use the joining guide for the available user steps. Sign-in and extra verification, creating a workspace and account recovery explain the related journeys.
Choose the right starting point¶
| Your situation | Starting point | What it achieves |
|---|---|---|
| You have never used this email with Zerohive | Create account, then activate it using the emailed code | A verified sign-in account; no automatic organization membership |
| An administrator invited your email before you registered | Activate the account if required, sign in, then review the invitation | Membership after you accept a still-valid invitation |
| You already have an account and received another invitation | Sign in to that account and open Invitations | A separate membership in the inviting organization |
| You have an account and know which organization you need to join | Send a join request using its short workspace name | A pending request for an administrator to decide |
| Your existing account was deactivated | Follow account recovery or contact the responsible administrator | Recovery of the existing account, subject to its restrictions |
| You need a new organization for your team | Follow workspace creation | A new workspace and its own commercial/setup journey |
An invitation to a different email belongs to the account associated with that address. Signing in to another account does not transfer it. Requesting membership also does not recover a deactivated membership or bypass the organization's email-domain restrictions.
Registration and email activation¶
Registration collects first name, last name and email. The password is chosen during activation. The backend normalizes the registration email and checks for an existing account before creating a sign-in identity. A duplicate email returns an existing-account result instead of creating another account or adding a membership.
A new account receives a six-digit activation code valid for 30 minutes. Activation checks the email, code, account state and expiry, sets the sign-in password, marks the email verified and consumes the code. Requesting a new code replaces the previous activation code. An account that is already verified or inactive cannot use this initial-activation flow.
The password rule accepts at least eight characters. Passwords of eight to fifteen characters need at least three of lowercase letters, uppercase letters, digits and non-whitespace symbols. A passphrase of sixteen or more characters satisfies this application rule. The sign-in service still has to accept the password. The current browser handler trims leading and trailing whitespace from password fields, so do not rely on those spaces being retained.
Completing activation returns the person to sign-in. It does not sign them in automatically, accept an invitation or choose a workspace. An activation message being queued also does not prove that it has reached the mailbox.
Invitations and seat capacity¶
An active organization administrator can invite a person as a member or administrator. The organization must be active, its email policy must allow the address, and capacity must be available. An existing inactive account cannot receive a new grant through this path. An active member cannot be invited again; a deactivated member needs membership reactivation; an already-pending invitation prevents another pending invitation.
Invitations expire after seven days. A pending invitation reserves one seat in the capacity calculation alongside active members who have product licenses. For example, if a workspace has ten licensed seats and eight active licensed members, two pending invitations use the remaining capacity. Another invitation or a join-request approval cannot be added within that ceiling. This is an access-capacity rule, not a promise of a particular invoice amount.
Accepting changes a pending membership to active and grants the products included in the organization's current plan. It retains the role chosen for the invitation. The backend rechecks the recipient's active account and current email policy. A recipient can accept or decline only their own invitation. Administrators can withdraw a pending invitation.
| Invitation state or outcome | Meaning for the recipient | Meaning for the organization |
|---|---|---|
| Pending and within its deadline | Can be reviewed and accepted or declined by its recipient | Capacity is reserved; the person has not joined yet |
| Accepted | Membership is active with the offered role and included products | Membership and product-access changes are propagated |
| Declined or withdrawn | This invitation can no longer be accepted | The pending reservation is released |
| Expired | Acceptance is refused even if the old item is still visible | Background cleanup removes the expired pending membership |
An expired item may remain visible and reserve capacity until cleanup succeeds. The deadline is enforced during acceptance; continued visibility does not extend it. Account and administrator notification requests are created after acceptance, but email arrival is not the authority for membership state.
Asking to join¶
An active account with verified email can request access to an active workspace using its short workspace name. The organization's allowed-email-domain policy applies. A person who already belongs to the workspace, has a pending invitation there, or has another pending request cannot create another pending request through this flow.
The optional note explains why access is needed. It does not select a role, confer approval or grant product access. A pending request can be cancelled by its sender. An active organization administrator can approve or reject it. Approval rechecks the requesting account, email policy and available seats, creates a normal member role, and grants the products included in the current plan. It does not make the requester an administrator.
The request lifecycle is pending, then approved, rejected or cancelled. Those outcomes end that request. A later request is a new record subject to the same checks. There is no request-expiry deadline in this flow. The current account list shows pending requests for active workspaces, not a complete decision history. A request disappearing therefore does not by itself tell you whether it was approved, rejected, cancelled or became unavailable because the workspace changed state.
Background processing and retained information¶
Registration publishes the account projection. Joining publishes membership, product-license and relevant product-projection changes. The sign-in service is also updated with the organization and role when the organization has its sign-in identity configured. These boundaries can fail or be delayed independently; a screen confirmation is not proof that every downstream product has finished updating.
Daily invitation cleanup removes expired pending invitations. It can also delete an unverified account left with no other membership and no join-request record after those invitations are removed, along with its activation code and sign-in identity. Verified accounts are not candidates for this cleanup. Any other membership, including a historical one, or any join-request record prevents that orphan-account selection. Administrators receive a cleanup-summary notification request.
The cleanup's identity-service failure prevents that processing attempt from finishing, and message retries are configured. It is not an instant expiry timer or a guaranteed email-delivery deadline. Ordinary account deactivation and recovery follow their separate lifecycle.
Current experience limits¶
The invitation email and messaging link currently point to a destination that is not implemented by the account frontend. A recipient can instead sign in normally and open the connected Invitations list. The invitation remains tied to the correct account and its original deadline.
The organization-administration Invite Member, withdrawal and join-request decision screens are previews. An administrator must not treat their sample lists or disappearing rows as completed access changes. Connected administration, its deployment and a full onboarding walkthrough remain unfinished work.
The join-request form currently expects a short workspace name even though its hint mentions a link. Failed list requests can appear as an empty list, and the Retry request action does not cancel an existing request. Activation failures share an overly specific expired-code message. These limitations are addressed in the task guide; they are documented observations, not fixes delivered by this documentation change.
What leaders should assess¶
For an onboarding rollout, distinguish accounts activated, invitations accepted, requests approved and people actually able to enter their licensed products. These are different milestones. Confirm that the organization's email rules, administrator responsibilities and available capacity suit the intended team. Do not infer production readiness, onboarding completion or a delivery SLA from the presence of backend endpoints or preview screens.