Membership, roles and permissions¶
Read product licences and access for newer assignment authority, licensed-person capacity and initial-administrator activation behavior. The existing screen guide remains separately verified.
Draft. Membership and permission services are implemented. The guide follows the intended Tenant Admin Final Screens; the inspected frontend uses preview data. Connected operation and environment availability still need verification. Live availability and reader acceptance remain unverified.
A membership connects a person's account to a workspace. It records their workspace role, branch, organization-head designation, membership status and product licenses. One person can belong to several workspaces, with different responsibilities and access in each. A change in one workspace must not be interpreted as a change to every organization they belong to.
This feature explains how those access decisions fit together. Use the member-access guide for the intended administrative steps and the workspace policy guide for domains, extra verification, working calendars and retention effects. Joining an organization owns invitations and join requests; workspace access owns choosing and entering a workspace.
The different layers of access¶
| Layer | What it establishes | What it does not establish |
|---|---|---|
| Account | The person's identity, activation and sign-in eligibility | Membership in every workspace |
| Membership | Their relationship to a particular workspace and whether it is active | Access to every product or action |
| Workspace role | Administrator or ordinary member responsibilities | All WorkOS, HiveOrbit or HiveAI permissions |
| Branch | Their workspace location and branch-dependent access | Their job position or reporting line |
| Organization head | Leadership designation that can feed approval authority | An administrator role or a product license |
| Product license | An active grant for a product | Permission to read every record or perform every operation |
| Purchased add-on and assignment | Commercial capacity and its allocation to a person | A replacement for the required base product license |
| Product permissions | Actions associated with the person's active product roles | An override of ownership, record access, governance or commercial checks |
For example, someone can be an active WorkOS member without Advanced HiveComms access. An administrator can manage workspace membership without automatically receiving every product permission. A person with a retained license can still lose access because their account, membership, branch or workspace is inactive.
Membership states and responsibilities¶
An invitation creates a pending membership. It becomes active through the invitation acceptance process. A join request is a separate request for admission; an administrator approves or rejects it. Do not treat every pending member as someone awaiting administrator approval.
The member directory includes active, pending and deactivated memberships. Cancelled memberships are excluded from its current read. Counts therefore describe recorded membership states, not concurrent users, available paid seats or everyone currently able to sign in.
Workspace administration requires the appropriate administrator authority. Membership mutations also check the acting account and active administrator membership, including branch access. Being an organization head does not satisfy that requirement. The inspected member-detail design displays the workspace role but does not provide a verified role-change journey. Do not assume that clicking a role label promotes someone.
Deactivation retains history and changes access¶
Removing a member through the current administrative backend deactivates their membership rather than deleting the membership record. It revokes their active product licenses and records the deactivation reason and time. Their previous license records remain available as history.
This is different from deactivating the person's account, removing their branch assignment or suspending the entire workspace. Membership deactivation retains the recorded role, branch and organization-head designation. It also retains purchased add-on assignments until those assignments are removed separately. A retained assignment can continue to occupy purchased capacity even while the member cannot use it.
The change initiates downstream access synchronization and can suspend enterprise roles anchored to that membership. It also requests HiveAI user-data deletion processing under the applicable retention and legal-hold policy. This is not proof that all data has been erased, that every connected session has ended immediately or that every background projection has refreshed.
The inspected member-removal path does not protect the last accessible administrator. Arrange administrative continuity before deactivating an administrator, including yourself. Membership removal does not automatically transfer their responsibilities, work or approval authority to another person.
Reactivation uses current eligibility¶
An administrator can request restoration for a deactivated member. The target account must be active, the workspace must be active, and the person's email must satisfy the current workspace policy. Available licensed capacity is checked when the current plan supplies products.
Reactivation grants the products included in the current plan. It does not simply reinstate the old license list. Historical revocations remain in the license ledger. The recorded workspace role and branch remain in place; an inactive branch can still prevent entry after membership restoration.
Review retained add-on assignments after restoration. They may become effective again if the base license, purchased capacity and other access conditions are satisfied. Previously suspended enterprise roles require separate review; this reactivation path does not itself unsuspend them. Restoration is not a guarantee that previously deleted information can be recovered.
Advanced HiveComms access and purchased seats¶
Advanced HiveComms is assigned separately from the product-license ledger. Granting a new assignment requires an active, accessible membership, an active target account, the required WorkOS license, a recurring add-on available under the current plan and unassigned purchased capacity.
Buying capacity and assigning access are different actions. The member-detail action allocates a purchased seat; it does not buy one. Removing an assignment releases that allocation but does not cancel the workspace's purchase or promise a refund.
When purchased capacity falls below retained assignments, effective access favors the earliest assignments, with stable tie-breaking. Assignments are retained even when they fall outside effective capacity. Inactive members' retained assignments can also consume capacity. Review allocations before buying more seats or assuming that all retained assignments are usable.
The current member-detail response does not expose a reliable per-member add-on assignment status or remaining-seat count. The intended design provides grant, removal and recovery actions without inventing such a counter. A product-license badge alone cannot confirm Advanced HiveComms access.
Product permissions and changing access¶
The server combines current workspace eligibility and product licenses with permissions supplied by active product roles. A role in a product determines which actions the person may perform there. Advanced HiveComms additionally requires its purchased assignment and existing WorkOS permissions; it does not replace those base permissions.
Tenant knowledge administration is a specific exception to the idea that every administrator task needs a chat seat: an accessible workspace administrator with the relevant HiveAI plan entitlement can receive knowledge-administration authority without a HiveAI chat license. That does not grant chat access or all HiveAI actions. See HiveAI access.
Access information is tied to the person's account, workspace and sign-in session. Some parts are cached. Product-role changes send background notices to clear cached permission information, but a saved role or membership change does not guarantee that every service and existing session reflects it immediately. Each operation still needs server permission checks; a visible button alone does not grant authority.
If product actions disappear unexpectedly, ask the access administrator to check the saved roles and current account, workspace and product eligibility. A problem obtaining access information can also leave a product without permissions. Preserve the existing assignments while support investigates; missing actions alone do not confirm that someone removed a role. Provide the workspace, affected action, approximate time and safe error reference, without sending sign-in tokens or codes.
Zerohive uses verification keys to check signed access information. Making those verification keys publicly readable does not expose a person's permission list or grant access to a workspace. The server still checks the person, workspace, sign-in session and requested action. If access verification is unavailable, that failure alone does not show that an administrator removed your membership; support must distinguish a service problem from an actual access change.
Availability and review limits¶
The inspected Tenant Admin pages contain a searchable member directory, member detail and add-on recovery previews. Their permissions and records are sample values. Grant/remove buttons are not connected to backend mutations, and membership lifecycle links currently lead to workspace lifecycle rather than a saved member action.
The documentation records these implementation gaps while retaining the Final Screens journey. It does not claim that the preview is a usable administration console, that the role label is editable, or that a designed operation has been deployed. The policy supplement explains intended editing and known save limitations; complete state/device coverage and implementation acceptance remain open. Full product-role administration, downstream revocation timing and audience walkthroughs remain part of the wider documentation reconciliation.