Create a workspace, start a trial and complete initial payment¶
Draft traced to the implementation snapshot for this feature. Domain review, design assessment, reader walkthroughs and live delivery verification remain pending.
A workspace is the organization boundary in which a team receives access to Zerohive products. Creating one records its identity, contact details, initial administrator, plan and licensed seat count. Zerohive then prepares its supporting services. If the selected plan requires an initial payment, payment must be verified before that preparation begins.
The person creating the workspace becomes its first administrator. This is an organization responsibility: it does not make the person platform staff, grant every product permission, or establish that every product application is available in the environment.
Use the creation and recovery guide for the current screen sequence. Read account sign-in and access if you cannot reach Workspace Access.
Who can create a workspace¶
Self-service creation requires an active account with a verified email address. An account with platform-staff authority cannot use this customer self-service flow. This restriction keeps platform operations separate from customer ownership.
You need an available country and an active plan permitted for self-service onboarding. A quote-only plan requires the commercial request process. Changing a plan name or entering a larger seat count cannot bypass that rule. The server also checks that the starting seat count falls within the plan's permitted range, including any applicable trial limit.
For an organization starting adoption, agree who will own the workspace, which contact email should receive billing and operational correspondence, and which team needs initial access. The contact email is not automatically the administrator's account. The signed-in creator receives the initial administrator membership.
Information recorded at creation¶
| Information | Meaning and important limits |
|---|---|
| Workspace name | The display name people recognize; required, up to 256 characters |
| Workspace link | A unique address label using lowercase letters, numbers and interior hyphens, up to 63 characters; it must begin and end with a letter or number |
| Company name | The organization's recorded company name; required, up to 256 characters |
| Contact email | A valid contact address for the organization; required, up to 256 characters |
| Phone number | A required contact number, up to 64 characters; the creation validator does not establish that the number can receive a call |
| Country | A currently active country from the catalog; influences selection of billing currency and configured tax treatment |
| Plan and starting seats | The chosen self-service plan and a positive number of licensed seats within its allowed range |
| Website and address | Optional organization details |
The intended design includes Region, but the current form omits it and the backend uses the environment's configured provisioning region. The organization's country does not select its hosting location. Confirm hosting requirements through the appropriate product or operational process; a country choice or sample design value is not evidence of data location.
Three paths after creation¶
| Selected plan's current rules | Initial payment | What happens next |
|---|---|---|
| A trial is enabled | No initial payment is requested by this creation path | The workspace enters preparation and its trial dates are recorded |
| No trial and the calculated initial seat charge is zero | No initial payment | Preparation starts without a paid checkout |
| No trial and the calculated initial seat charge is positive | An initial subscription payment is prepared | Workspace creation is saved while it waits for verified payment; preparation follows successful billing |
The creation response can arrive before a payment step is ready. Saved, checkout ready, payment verified and workspace active describe different milestones. Returning from the payment provider or seeing a payment link is not proof that all milestones have completed. A trial or zero-charge start has a workspace identity without a real paid-checkout reference.
Preparation includes the organization's identity setup, default settings, private document storage and public routing configuration. These operations run in the background. Infrastructure or provider failures can leave the workspace pending even though its initial record exists. No fixed completion time is promised by this documentation.
Prices, currency and the final amount¶
The initial seat subtotal is calculated from the current plan price and starting seat count. The backend first looks for an active price in the selected country's currency, then uses an active default price if no matching currency is available. If neither exists, creation cannot obtain a valid billing profile.
The paid billing workflow can add configured country tax before creating checkout. Review the latest currency and Amount due now before paying. The plan-selection estimate and the first saved summary can precede that final calculation. For a trial, the current no-payment summary can show the initial subtotal offset by a discount; that display does not promise a permanent price reduction or free renewal.
The current application loads live plans for the selected country and clears earlier choices when that country changes. Failed or empty catalog reads prevent a valid self-service selection. Its review page obtains a server preview before creation; configured tax and later changes can still affect final checkout. A preview, plan label or unavailable price does not establish a free offer, reserve terms or prove that creation succeeded.
For an eligible paid start, the current review offers explicit consent to save a card for automatic subscription renewals. Trial/free creation does not collect that choice through this flow. Authorizing it is a commercial decision for the payer; a checked box or saved workspace does not prove that a usable payment credential exists or that renewal will succeed. Manual-method availability, current payment status and continuing subscription rules still apply. The task guide explains the choice and its design/implementation difference.
Self-service plans and a commercial quote¶
The plan catalogue lists active plans currently offered for self-service. An Enterprise Plus offer can require a separate quote and therefore be absent from that list. A missing plan does not mean it can be activated by changing a name or seat count. Plan details describe possible entitlements and limits; a successful catalogue load does not reserve a price, seats or product access.
Currency is selected from available pricing, with a default price when a matching currency is unavailable. The current plan-selection request includes the selected country's code; the server preview resolves country, plan and starting seats again. Creation rechecks its own eligibility and billing profile, so an earlier display is not a reservation. Confirm the final checkout currency and amount before payment.
An Enterprise Plus request records organization and contact details, an active country, a whole seat count meeting the current published minimum and optional commercial needs. The application displays the minimum; 251 is not a permanent rule. The acknowledgement confirms a saved request for commercial review, not an approved price, contract, workspace, payment or delivered notification. The submitting account can retrieve its current request status; possession of a reference does not grant another account access. Quote acceptance does not establish later workspace eligibility in that country. Private Cloud interest remains a request to discuss it; the capability is disabled. Follow the quote guide and retain the original submission details if the outcome is unclear.
Trials and their end date¶
Trial duration, reminder checkpoints, allowed starting seats and the fallback plan come from the plan's configured policy. The trial starts when the subscription is created. The code does not reset its start date after background preparation finishes, so preparation delay can consume part of the recorded trial period.
A daily background process checks trials. It requests reminder emails for active organization administrators at applicable checkpoints. If processing missed earlier checkpoints, it sends the latest due reminder and records the earlier ones as handled. Email dispatch depends on valid recipients and working message/email delivery; receiving no reminder does not extend the trial.
When a trial expires, the implementation attempts to move the organization to its configured fallback plan and reset it to billing without an external recurring-subscription reference. This is a plan transition with real access consequences. Products absent from the fallback can lose their licenses, and a lower seat limit can deactivate excess licensed memberships. The retention rule protects an eligible organization head and an administrator where present, then fills remaining seats by earliest license grant, with a stable identity tie-break.
An invalid or ambiguous fallback configuration can prevent the transition and requires operator attention. The process does not justify a promise that every expired trial always completes its transition immediately. Administrators should review the trial end date, intended continuing plan and affected team access before the trial ends.
Unfinished payment and recovery¶
Pending initial-payment workflows can expire. The checked-in billing default is 24 hours, with a configurable value and periodic processing; this is not an exact countdown guaranteed for every environment. When an initial workflow expires while its workspace is still waiting for payment, the workspace is deprovisioned and its subscription cancelled. A workspace already preparing or active is not deprovisioned by that awaiting-payment handler.
If payment or preparation appears stuck, use the existing workspace and checkout reference to investigate. Repeatedly creating another workspace does not reconcile the first attempt. The current checkout page clears older results when its latest read fails; that failure does not prove an unpaid balance or undo a saved payment. Current pending-status polling is bounded, and a recovery-list entry or label is not payment authority. Request a replacement checkout only through the action offered after current evidence permits it, or seek support when the outcome remains uncertain.
Availability and remaining limits¶
The App contains creation, plan selection, review and checkout screens. Application availability must be confirmed for the environment you use. Creating an active workspace does not by itself enable every administration or product application. Product access also retains its own membership, entitlement, permission and environment checks.
The current implementation now loads country-specific plans, obtains a server preview, stores owned temporary drafts, recovers status references and carries saved checkout currency. It does not reproduce every intended Final Screens companion. Hosting-region and renewal-consent design, truthful no-payment/trial wording and recovery prototype destinations remain open design work. The recovery hub can still show misleading empty/payment labels, and implemented native-payment service/actions do not establish a mounted payment form. The guide explains the current entry and recovery limits. Full source, commercial, design, environment and reader acceptance remain pending.