Staging draft Work in progress · For review; coverage and acceptance incomplete

Prepare and set up an organization

Organization setup establishes the workspace, accountable administrators, membership, access and the configuration needed for the chosen work. It is more than creating an organization name.

This guide provides a preparation and verification order. The linked feature guides own the exact screen steps, prerequisites and recovery. It does not create a separate setup wizard or imply that every control is connected.

Draft and availability: Workspace creation has implemented backend behavior and connected account entry points, while several Tenant Admin controls remain previews. Deployment eligibility and the actual connected journey must be verified separately against the current source and environment. Follow the documented availability for each stage; this guide is not evidence of a completed deployment.

1. Agree who owns the workspace and the initial scope

Identify the organization's accountable owner, initial administrator, billing contact, information owner and support route. Choose the first process or team that will use the platform and the products it needs.

The adoption guide helps define a bounded scenario and evidence for a rollout decision. Do not assume that every workspace begins with the same forms, approval bodies, calendars or retention configuration.

The creator receives the initial administrator membership. The workspace contact email is a separate recorded contact; it is not automatically the administrator account. Agree these responsibilities before creation.

2. Establish the account and commercial prerequisites

Use account setup and sign-in for the intended creator. Self-service workspace creation requires an active, email-verified account; a platform-staff account cannot use that customer self-service flow.

Review the active plan permitted for self-service onboarding, starting seats and the actual commercial terms. Quote-only arrangements use their own process. The workspace-creation guide explains plan and payment branches.

A trial follows the selected plan's current rules. It does not establish a universal trial duration or free renewal. For paid creation, the initial payment must be verified before provisioning starts.

Use the current commercial summary, including currency and any applicable tax. Sample prices and fallback labels are not a quotation. Read usage and capacity and Billing before making a commitment.

3. Create the workspace and verify its preparation

Follow Create a workspace. Confirm the identity, contact details, workspace address label and chosen commercial arrangement before submitting.

Creation can produce several milestones: a saved workspace, checkout preparation, verified payment, background preparation and active workspace access. Not every plan requires payment, and a saved creation response does not prove every supporting service is ready.

If the result is delayed, use the original creation or checkout recovery path. Preserve its reference and confirm the saved state before creating another workspace.

The form's region entry does not choose the backend provisioning region. Confirm actual hosting requirements with the responsible owner; country or branch labels are not proof of where data is stored.

4. Establish structure and preserve administrator access

Use workspace structure for branches and organization-head designations. Branches group people by physical location; departments, reporting lines and positions belong to the separate People and organization structure.

Confirm which administrators can still access the workspace after a branch or membership change. The current paths do not guarantee that the last accessible administrator is preserved.

An organization-head designation does not itself grant an administrator role or product licence. It can affect synchronized approval-body membership in WorkOS. Verify the governance relationship when the designation matters to decisions.

A saved structure update does not prove that every dependent view or pending workflow has refreshed.

5. Establish policies, members and product assignments

Use the access-policy guide for supported email-domain, extra-verification and working-calendar configuration. Review the effect on the actual account and membership paths before relying on a changed rule.

Invite people or review their requests through the joining guide. Sending an invitation does not accept it for the recipient. Sending a join request does not make the requester a member.

Use member administration to confirm identity, role, branch, product access and any purchased add-on assignment. Commercial capacity and individual assignment are separate.

Several administrator controls currently operate on sample data. Use the intended guide to understand what must eventually be verified; do not communicate a membership or licence change as completed solely from a preview success message.

6. Prepare the configuration for the chosen work

The organization should prepare only the capabilities in its agreed scope, using their own owners and rules.

Chosen use Configuration and ownership to review
Repeatable requests Workflow authoring, request definitions and eligible routing
Governed decisions Approval bodies and signing authority
Timed work SLA policies and the organization's working calendar
Retained information Records, classification, access and lifecycle
Contribution insight HiveOrbit initial setup, role expectations, sharing choices, reporting calendar and source/admission readiness
Governed assistance HiveAI access, governance and credit controls

A listed capability or registered default does not establish that the required tenant configuration is complete. HiveOrbit preparation preserves existing choices and can install drafts without enabling scoring. Its activation decision separately checks applicable people, licences, role expectations, calendar, sharing and recent work-source synchronization. A scheduled start, a saved setup and a working report are different outcomes. Current access or prerequisite changes can stop processing later; restoring access does not automatically change every historical receipt or reopen an interrupted admission. Follow the detailed setup and eligibility guides for the actual decision and recovery limits. Provider approval does not prove provider provisioning. Private Cloud remains disabled.

7. Verify the actual participant journey

A representative participant should be able to establish the intended account, membership, workspace and available product context before attempting the chosen task. Use Getting started and the relevant feature guide.

Check normal completion and the relevant access, delay, changed-state and recovery cases. Identify which results were observed in the chosen environment and which remain design intent or unverified implementation.

A successful administrator login, workspace count, product card or healthy service check does not establish that the whole participant journey works. Keep unresolved gaps and their owners visible before expanding adoption.

Return to administrator responsibilities or access, billing and lifecycle when a prerequisite or outcome needs investigation.

Zerohive documentationStaging draft · 22 Oct 2026

Search documentation

Search guides, platform concepts and tasks.

↑ ↓ to move Esc to close