Deactivate an account and recover the same account¶
Draft based on the recorded implementation. The email-to-browser recovery handoff is incomplete at this source snapshot. Reader acceptance, design reconciliation and live delivery verification remain pending.
Account deactivation stops a person's account from accessing Zerohive while retaining its identity and existing assignments. Recovery restores use of that same account after the required authority checks and identity-provider work complete. These operations matter when a person pauses use, an administrator restricts access, or an installation needs an existing administrator recovered.
Deactivation applies across the account's workspaces. Removing a person from one organization, revoking a product license, cancelling a subscription and deleting personal data are separate operations with separate consequences. Deactivation alone does not complete any of those processes.
The task guide explains the current user entry points and recovery limitations. Sign-in and sessions explains the fresh sign-in required afterward. If the account is active and you have forgotten its password, use password recovery; resetting a password does not reactivate a deactivated account.
Who can act¶
| Situation | Available authority | Important boundary |
|---|---|---|
| You want to deactivate your active account | You, from the live My profile flow | The change affects the whole account |
| Platform staff need to restrict an account | An authorized platform Administrator | Being an organization administrator does not confer this platform role |
| You deactivated your own account and previously verified its email | A single-use recovery email can authorize recovery | The current browser handoff has a known implementation gap |
| An administrator deactivated the account | An authorized platform Administrator | The self-service email flow cannot override that restriction |
| An older inactive account has no proven self-deactivation history | An authorized platform Administrator | An inactive account is not automatically eligible for self-service recovery |
| An initialized installation has no active platform Administrator | An eligible server operator through the controlled recovery procedure | The target must already retain the Administrator role and its existing identity |
Zerohive prevents deactivation of the final active platform Administrator. Another ordinary account does not satisfy this protection. Operator recovery is a narrow contingency for an existing administrator; it does not create a replacement identity or grant a missing role.
What is preserved¶
The lifecycle operation retains the platform account and identity-provider identity, verified-email state, extra-verification enrollment, staff roles and organization assignments. It does not remove existing memberships or release their product-license, reserved-seat or seat-add-on allocations. Retained allocations can continue to consume capacity. Do not use account deactivation as a cost-reduction or subscription-cancellation procedure.
An inactive person cannot use retained privileges. New explicit access grants are guarded against inactive accounts, and separate administration workflows can revoke existing assignments. Recovery uses what remains at that time. It does not reconstruct assignments previously removed, restore revoked permissions, or replay every grant skipped while the account was inactive.
Managers should therefore distinguish access containment from reassignment and commercial administration. Review work ownership, organization membership and licensed capacity through their respective processes instead of assuming a single account action completes an offboarding checklist.
When access stops and when recovery completes¶
Deactivation records the account as inactive and invalidates earlier sessions before its background identity disable/logout work finishes. A delayed identity-provider response does not make the inactive account eligible to pass the account-access checks.
Recovery first records a pending operation while the account remains inactive. Background processing enables the existing identity and logs out its existing sessions. Only successful completion records the account as active. Recovery accepted and account ready are different milestones.
An intervening account restriction can supersede an older recovery request. The older request cannot complete a newer account state. Provider failures remain pending for retries and operational investigation; the implementation does not promise a fixed recovery completion time.
After completion, sign in afresh with the existing account credentials and applicable extra verification. Refreshing an old session does not make it valid again. Product access still depends on the current workspace, membership, entitlement, license, permission and delivery conditions.
Recovery email and privacy¶
The request screen gives the same neutral acknowledgement for eligible, ineligible and unknown accounts. This protects account privacy; it is not confirmation that an email was sent or that the account exists.
A self-recovery link expires after 30 minutes, is single-use and belongs to the account state that issued it. A newer eligible request replaces an earlier challenge. Once recovery is pending, repeated email requests do not start independent recovery operations. Rate controls also limit requests and email dispatch.
Confirmation returns a private status receipt, valid for up to 24 hours. The receipt lets the client check that recovery operation; it does not sign the person in. Keep recovery links and receipts private. Support can investigate using non-secret account and operation references without collecting a password or recovery link.
Current frontend limits¶
The live My profile page submits account deactivation. A separate companion deactivation page still uses sample profile content and a navigation-only confirmation; reaching its signed-out page is not evidence that deactivation occurred. Use the live profile entry described in the guide.
The recovery request, confirmation and status screens exist, but the email destination and the frontend's token intake do not match in the inspected implementation. No working end-to-end email recovery is claimed. If the email cannot reach a usable confirmation screen, ask the authorized support or platform administration team for assistance; manually changing a private recovery URL is not a documented workaround.
The Admin interface supports deactivation, but its warning says memberships are cleared even though the lifecycle implementation preserves them. That wording must be reconciled. A matching Admin recovery control was not found in the inspected client, although the administrator recovery API exists. These are open implementation/design-assessment items, not completed fixes.