Review and manage a member's access¶

Intended journey. These steps follow Tenant Admin's Final Screens. The inspected member-management screens use example records, and their controls do not yet save these changes. Check availability with the responsible platform team before using this guide for live administration.

Use member administration when someone joins, changes responsibilities, needs a purchased add-on or leaves your workspace. The membership overview explains how account status, workspace role, product licenses and permissions work together. For workspace-wide email domains, extra verification and working calendars, use the access-policy guide.

Before changing access¶

Work in the correct workspace and use an eligible administrator account. An organization-head designation alone does not make someone an administrator. Your membership and branch must permit administration.

Confirm the person's identity and the intended change. Removing a branch assignment, removing an add-on, deactivating a workspace membership and deactivating an account have different effects. For administrators, arrange another accessible administrator first: the member-removal path does not automatically preserve the last one.

If the person is joining for the first time, use invitations or join requests. A pending invitation requires the invited person's acceptance. A join request requires an administrator's decision. Restoring an old membership is a different task.

Find the member and understand their status¶

1. Open the intended workspace's Tenant Admin area and select Members.
2. In Member Directory, search by name or email. Use Status, Role or Branch to narrow the list. Check email as well as display name when people have similar names.
3. Choose Open for the person. The intended inactive-member row uses Restore to lead toward restoration; it should not be treated as proof that restoration has already happened.
4. Review the membership, workspace, branch and security summaries. Then review Access and Assignment, Product Licenses and the invitation history.

The directory also offers Invitations, Join Requests and Organization Heads tabs. Use the relevant tab for that task rather than treating all access issues as membership restoration.

An active membership is only one part of access. An inactive account, branch or workspace can still block the person. A product license can be revoked while other licenses remain active. A displayed license or system-access result does not establish every product permission or every record the person may read.

The current backend detail does not provide a per-member Advanced HiveComms assignment badge or an available-seat counter. Use its separate add-on actions and their results; do not infer add-on access from the WorkOS license row.

Change a branch or organization-head designation¶

Under Member Management, the design offers Change branch, Remove branch, Designate org head and Remove org head. Follow the branch and leadership guide for those journeys.

Removing a branch leaves the person in the workspace. An organization-head change does not itself change their administrator role or product licenses, but it can affect synchronized approval authority. Review work that depends on that responsibility before changing the designation.

The role shown on this page is informational in the inspected design. A connected promotion or demotion action has not been verified. Do not interpret the role label or a product-license row as an editable control.

Grant Advanced HiveComms access¶

1. Open the correct member's detail page and find Advanced HiveComms Access.
2. Check that the person has an active account, accessible membership and WorkOS access. The workspace must have purchased the add-on and have capacity available for assignment.
3. Choose Grant access when that connected action is available. The backend checks current eligibility and capacity when the request is submitted; a previously viewed summary cannot reserve a seat.
4. If the screen says Advanced HiveComms seats are needed, use Open Billing to review the purchase or add capacity, then return to the member's page. Before purchasing more, review whether unused retained assignments should be released.
5. Confirm the saved action result and the person's effective product access. A click, changed preview or license badge alone is insufficient evidence that access was granted.

The member action assigns capacity already purchased. It does not itself buy the add-on. The current Figma prototype incorrectly sends its add-on actions to branch assignment, and the frontend buttons are not connected; those gaps are tracked. Do not use the branch screen as a substitute for granting add-on access.

Remove Advanced HiveComms access¶

1. Open the member's detail and review Advanced HiveComms Access.
2. Choose Remove access when the connected action is available.
3. Confirm the action result. If No active Advanced HiveComms access found or Nothing to remove appears, the intended recovery state means no assignment was removed. Recheck the selected member and workspace before escalating an unexpected result.

Removing an assignment releases its allocation. It does not remove the person's WorkOS license, deactivate their membership, cancel the workspace's purchased add-on or promise a credit. Billing changes are separate.

A deactivated member can retain an add-on allocation. The backend supports removing that retained assignment without first restoring the person's membership. Review these allocations during offboarding so unused assignments do not continue to occupy capacity.

Deactivate a membership¶

1. Find the correct person and review their active products, branch, leadership responsibilities and add-on needs.
2. Arrange a replacement administrator or responsible colleague where necessary. Record how their unfinished work will be handled; membership removal does not transfer it automatically.
3. On member detail, use Member Management → Lifecycle → Deactivate member when that member-specific action is connected.
4. Check the saved membership state and product-license results. Release retained add-on assignments separately when appropriate, and review affected enterprise authority with its responsible administrator.

The inspected design has the action label, but its confirmation and completed-outcome sequence is not yet verified. The current frontend link leads to workspace lifecycle, which affects a different object. Do not suspend or delete the workspace to remove one member.

The backend deactivates this membership and revokes its active product licenses while retaining history. It retains the person's recorded role, branch, head designation and add-on assignments. It initiates access synchronization and HiveAI data-retention processing; it does not establish immediate erasure or immediate termination of every connected session. Their account and other workspace memberships are separate.

Restore a deactivated member¶

1. Find the inactive member using Status, then use Restore or open their detail as supported by the completed interface.
2. Confirm that their account is active, their email meets current workspace policy and the workspace is active. Check available licensed capacity and the current plan's products.
3. Review their retained role, branch and add-on assignments. An inactive branch can still block entry after membership restoration. Arrange for an eligible administrator to restore the branch, or change the person's branch assignment after their membership is active again.
4. Use Reactivate member when the connected member action is available, then confirm the saved membership and license state.
5. Have the member return through workspace access. Review enterprise-role restoration separately where applicable.

Restoration grants products from the current plan, which may differ from the products the person previously used. An inactive branch can still block entry. Retained add-on assignments can become effective again when their prerequisites and purchased capacity permit it. Previously deleted data is not promised to return.

Do not use restoration for a pending invitation or as a replacement for accepting an invitation. The complete restoration confirmation and outcome journey still needs design and implementation verification.

If access still fails¶

Permission data and downstream access records can be cached or updated in the background. Re-entering the workspace can obtain refreshed session information, but it does not guarantee that every underlying permission cache or projection has refreshed. Avoid repeatedly changing roles or buying capacity to work around an unexplained denial.

For support, provide the workspace, affected person's email, attempted action, approximate time and nonsecret error text. Do not send passwords, verification codes or access tokens. Administrators should explain the intended responsibility so support can distinguish a missing license, missing permission and a deliberate restriction.

Managers and executives can use this same review to check access ownership, administrative continuity and unused paid allocations. Member totals and administrator labels alone do not prove least-privilege access or complete offboarding.