Permissions, roles and changing access¶

A product licence makes a person eligible for a product; permissions describe actions they may perform. Zerohive builds a signed set of permissions for the person's organization session, using current membership and commercial access together with the relevant product's role information.

This explanation describes the implemented permission rules. Use the membership guide for inspected screen journeys. The frontend remains in progress, and a visible control alone does not establish permission to complete an action.

What determines your permissions¶

Your account must be active and your sign-in must remain valid after any account-wide session invalidation. You must belong to the selected organization with an active membership and active branch access.

Commercial coverage is checked before product permissions are returned. If coverage is blocked, the permission set contains no product actions even if role information was previously saved. Administrative billing recovery has its own access rules; it does not grant product use.

For ordinary product access, Zerohive asks the permission provider for each active product licence. WorkOS and HiveOrbit obtain role permissions through the workforce service. The HiveAI permission request also resolves workforce role data, through its message-based provider path. Each product receives its own relevant permissions, which can differ even for the same person.

A permission to use a feature does not give access to every record, remove a document's restrictions, authorize every transaction or override governance. The service handling the action retains its own checks.

Limited permissions for organization administrators¶

An eligible organization administrator with a WorkOS licence and an applied plan including WorkOS receives a limited set of setup permissions: create, edit and view roles, and view and edit staff. These support configuration even when the person has no separately assigned WorkOS role yet.

The corresponding eligible administrator with a HiveOrbit licence and an applied plan including HiveOrbit receives configuration-management permission.

These grants do not make the administrator unrestricted across either product. They do not create a permanent product role or change ordinary members into administrators. When a new permission set is issued, changes to the administrator role, personal licence or applied plan affect these additional grants.

Someone who holds a delegated product role can independently retain permissions from that role without being an organization administrator. Removing an organization-administrator designation is not the same operation as removing every product role.

Tenant knowledge administration is a separate responsibility¶

When the organization has the required HiveAI entitlement and usable coverage, an eligible organization administrator can receive permissions to manage tenant knowledge, authorize its processing and publish it without holding a personal HiveAI chat licence.

These permissions do not grant general assistant use. They come from the platform's current administrative authority; an ordinary product role cannot grant them on its own. Losing that administrative authority removes these additions when a new permission set is issued.

The actual knowledge operation still has its own source, governance and commercial requirements. Having the permission is one prerequisite, not confirmation that processing or publication has occurred.

Paid add-ons and enterprise capabilities¶

An add-on assignment must still be active and within its purchased capacity, with its base-product conditions satisfied. The permission builder adds its specific permission only when the underlying product already has a nonempty permission set at that stage.

An add-on purchase therefore does not repair missing product roles, and a retained assignment is not sufficient proof of effective access. See membership and add-ons.

The organization's applied plan can also contribute enterprise capability indicators. These describe available capabilities; enterprise membership, resource authority and the operation's own checks still determine how a person may use them.

Why permissions may change between sessions¶

Some product-role results are cached. A new signed permission set can reuse those results while checking current account, membership, licences and commercial coverage again. Its recent issue time does not necessarily mean that every product role was fetched at that moment.

Role-change notifications request cache invalidation. Delivery, cache updates and an already-issued permission set are separate stages, so a change is not a promise of instant updates in every open screen.

If a product's permission service fails or times out, actions supplied by that service can be absent from the new permission set. This does not by itself mean the person's licence was revoked. Specific platform-derived administrative permissions follow their own rules.

A forced fresh lookup that fails can return fewer actions for that attempt while retaining earlier role information for a later cached lookup. The system's cache duration is therefore not a simple guarantee that every role change will appear after a fixed wait.

Expiry and recovery¶

Permission sets have a limited lifetime. Where a commercial-access deadline applies, the issued expiry is shortened to that deadline. Renewing a permission set does not extend paid coverage or override the end of a trial or grace period.

A document's signature establishes its origin and integrity. It does not make permissions permanent, establish that a product is deployed or replace the receiving service's authorization checks.

How a request uses your permissions¶

For the inspected product request paths, Zerohive checks the signed permission set against the signed-in person, selected organization and current access token. A permission set from another organization or an earlier access token cannot be substituted for the current one. After a token changes, the application needs the matching permission set as well.

Passing this check establishes the permission information available to that request. The requested action can still require a particular permission, current membership, access to the relevant record and other product rules. An empty permission set can be validly signed while granting no actions.

If the system cannot obtain the public keys needed to check a permission set, the request may fail even though the person's role has not changed. Reassigning a licence is not a remedy for a key-service outage. Support should distinguish session mismatch, expired permission information, missing action permission and a service problem before choosing a recovery action.

When an expected action is unavailable, distinguish a changed role or licence from expired coverage, a restricted account or membership, and a temporary permission-service failure. Preserve the organization, product, action, approximate time and displayed message for the administrator or support reviewer. Do not send access tokens or signed permission documents through ordinary support messages.

The product-access explanation covers assignment and initial licensing. Repeating an existing licence assignment does not repair every permission or session problem.

See organization access and session renewal for selection, additional verification, administrator recovery and refresh outcomes.

See product roles and delegated permissions for role activation, staff assignments and the difference between role detail people and effective permissions.