Platform staff access¶
Draft based on the recorded backend implementation and intended staff screens. The frontend connects to staff services but has access-display and recovery gaps. Design corrections, deployed availability and reader acceptance remain unverified.
Platform staff are the people operating the Zerohive service. Their roles govern access to the Platform Console, including service support and commercial administration. Workspace administrators manage their own organization through a separate set of memberships and permissions. Being an employee, manager, executive or workspace administrator does not automatically make someone platform staff.
For example, an operating team can give a support colleague the Support role and a finance colleague the Billing role. A platform Administrator manages those assignments. Giving the support colleague a platform role does not enroll them in every customer workspace or replace the separate checks for a particular support action.
Roles and responsibilities¶
| Platform role | Responsibility and limits |
|---|---|
| Viewer | Access to console operations that require the viewing role, including the staff directory. It does not authorize changing staff access. |
| Support | Includes viewing access and operations protected by the Support requirement. It does not include Billing or Administrator authority. Individual support actions retain their own prerequisites. |
| Billing | Includes viewing access and operations protected by the Billing requirement. It does not include Support or Administrator authority. |
| Administrator | Satisfies viewing, Support, Billing and Administrator requirements. Only this role can add, replace or revoke staff assignments. |
A person may hold several roles. Support and Billing are separate responsibilities; holding one does not imply the other. Removing Support from someone who still holds Administrator does not remove their administrator-derived support authority.
These descriptions explain the role hierarchy. They are not a promise that every service action is available merely because a role is assigned. Account status, sign-in, verification, the requested operation and service access controls can also affect access.
Network access and staff authority¶
The console can also restrict the networks from which people connect. When that optional restriction is enabled, using an approved network does not grant a staff role or replace account verification. A network or configuration problem can prevent a request from reaching the account and role checks.
If the console is unavailable from your current network, retain the visible message and approximate time, and use the approved connection or contact the operating team's support channel. Repeated password or role changes do not resolve a network restriction. If an earlier staff change has an uncertain result, the operator must reconcile that original change before repeating it; inability to reload the console does not prove the change failed.
What an access change does¶
| Action | Result |
|---|---|
| Add or promote staff | Finds the account by email, or creates an account if none exists, and adds the selected roles. Existing roles remain. Entered names do not rename an existing account. |
| Update staff roles | Replaces the person's assignments with the selected set. At least one role is required. Use revocation when all staff access should end. |
| Revoke staff access | Removes all platform staff roles. It retains the person's account, workspace memberships and account history. This is separate from account deactivation. |
New accounts and accounts whose email still needs verification require activation. An existing active account with verified email can use its existing sign-in journey; receiving a new role alone does not require a replacement account or password. Staff access also requires the normal console entry checks, including the required multi-factor authentication setup. A successful role assignment does not prove the person can already enter the console or that an email arrived.
Inactive accounts cannot receive staff access. The implemented role replacement also refuses inactive accounts; removing their retained staff access uses revocation. Account recovery is a separate decision, explained in account deactivation and recovery.
Protecting administrative continuity¶
The service prevents removing the Administrator role from the last active platform Administrator and prevents revoking that person's staff access. The operating team should still verify that another administrator can actually sign in before handing over responsibility. The safeguard counts an active account with the role; it does not prove that the other person has completed activation, configured extra verification or retained working credentials.
Role changes are evaluated through refreshed authority checks. They are not defined as waiting only for the next sign-in. At the same time, an access change is not a promise that every existing session is immediately terminated. Staff should verify the resulting permissions, and report discrepancies through the operating team's support process.
What each audience needs to know¶
| Reader | Practical responsibility |
|---|---|
| End user or external participant | Use your normal account and workspace access. Contact support when needed; you do not need a platform staff role to use your organization. |
| Manager | Request access appropriate to the person's operating duties and review it when duties change. Team leadership inside a workspace uses separate permissions. |
| Executive or service sponsor | Assign accountability for service-wide access, maintain a usable administrator succession path and arrange regular access reviews. Role assignments alone do not establish a compliance certification or a complete audit trail. |
| Workspace administrator | Manage your organization's memberships and permissions. Escalate service-wide administration to the operating team. |
| Platform staff and support | Check the account and intended role before changing access. Use the private staff procedures for confirmations, denied access and uncertain outcomes. |
Staff role assignment contains no purchase, price or seat selection. It does not itself buy a subscription or allocate a workspace product license. Commercial arrangements remain separate; see subscriptions, invoices and payment.
When the result is unclear¶
A request can fail to return a clear result after some work has occurred. An error message, delayed email or stale screen is not enough to establish whether access changed. The operating team must check the saved assignments and account outcome before repeating the action. Deactivation and revocation should not be used interchangeably as troubleshooting steps.
For an access problem, provide the service address, approximate time, affected account identifier and the visible message through the approved support channel. Do not send passwords, verification codes or session tokens. Use account activation or sign-in and sessions when the problem concerns those stages.
Availability¶
The intended design includes a searchable staff directory, an add-or-promote dialog, a role editor and a revocation confirmation. The frontend makes real staff requests, but its role visibility and selected-person handling need correction. Some design wording and empty-state details also need updates. This draft records the intended experience and current rules without claiming those gaps have been fixed or deployed.
The platform owner is the initial reviewer for public and business guidance. That walkthrough and environment verification remain pending. Privileged operating steps and implementation evidence stay in private GitHub documentation.