Pause and restore workspace access¶
Draft documentation. The backend supports workspace suspension and reinstatement. The intended Tenant Admin journey follows the newer Final Screens, while the inspected frontend still uses preview data and local state changes. A connected deployment and audience acceptance have not been verified.
Pausing a workspace restricts ordinary access to its products while retaining the workspace for recovery. It is useful when an authorized administrator needs a temporary access interruption. A workspace can also be suspended through recurring-payment recovery controls or authorized platform operations.
Use the task guide to understand the intended pause and restore journey. If only one person's access needs changing, start with membership and access. If that person's entire account is inactive, see account deactivation and recovery. These controls have different scopes.
What changes when a workspace is paused¶
The workspace moves from active to suspended. Its suspension reason and time are recorded. Ordinary product requests are denied once the current suspended state is observed. The workspace and its memberships remain; suspension itself does not delete them.
A workspace pause does not deactivate everyone's account. Eligible users can still authenticate, but selection of a suspended workspace for recovery requires current administrator membership and the other account, membership and security checks. Ordinary members are directed to an administrator. A recovery context grants no ordinary product access. Other workspaces have their own access conditions.
The pause is not a promise that every background process, already-running action, external integration or existing connection stops immediately. It also does not establish that records are legally held, billing has been cancelled, a refund is due or data has been deleted. Arrange those separate requirements with the responsible administrator or support team.
Who may act¶
| Reader | Responsibility |
|---|---|
| Workspace administrator | Confirm the selected workspace, assess the effect on people, record the reason and verify recovery |
| Manager | Coordinate affected work and identify a responsible administrator; a management title alone does not grant lifecycle authority |
| Executive or business owner | Agree the business reason, continuity arrangements and recovery conditions; distinguish an access pause from commercial cancellation or permanent closure |
| Member or external participant | Report the affected workspace and error to the administrator; do not attempt a new payment or account registration merely to bypass the pause |
| Platform support | Investigate the cause and use authorized support procedures where self-service recovery is unavailable |
An organization-head assignment alone does not grant workspace lifecycle authority. The intended page's people and governance counts describe the workspace; they are not proof that every counted person can administer it or will regain product access.
Pause, restore and close have different consequences¶
| Action or condition | Meaning |
|---|---|
| Pause access | Temporarily suspend ordinary product access for an active workspace |
| Restore access | Return a suspended workspace to active status, while retaining other account, membership, policy and product-access checks |
| Close workspace | Use the separate permanent closure process; it cannot be reversed through Restore access |
| Deactivate one member | Change that person's workspace membership rather than the whole workspace |
| Deactivate an account | Apply account-wide restrictions through a separate process |
| Payment needs attention | Investigate the billing record; this can lead to suspension but is not the explanation for every pause |
A workspace awaiting initial payment or still being provisioned is not the normal pause-and-restore journey. Follow workspace creation and activation instead. Do not use restoration to bypass unfinished provisioning.
What permanent closure actually records¶
Permanent closure places the workspace in a terminal closed state and cancels its subscription in the platform's records. Restore access cannot reopen it. Current administrator authority is required, and the subscription must still permit cancellation; an already cancelled or expired subscription can cause this closure path to reject the request.
The system calls the configured public-route cleanup and requests an updated billing record, but the closure result alone does not prove identity cleanup, full data erasure, payment-provider cancellation or a refund. Export, retention and deletion-job decisions need their own reviewed process and evidence. The current closure API does not check that those prerequisites have been completed.
The frontend close confirmation is not yet connected to the backend operation. Do not treat dismissing its dialog, a disappeared route or an error after submission as proof of the final outcome. Authorized operators should reconcile the existing workspace and subscription before retrying. This page explains the implemented boundary; a complete closure walkthrough remains to be verified.
Why a workspace may become suspended¶
An authorized administrator or platform support operator can request suspension with a reason. Recurring subscription failures can also request suspension when the configured failure threshold is reached. The current default is three failures, but the threshold is configurable. The system still checks current subscription access and preserves an existing non-billing pause. A failure count is not itself proof that suspension occurred or a promised grace period or provider retry schedule.
The inspected payment handling distinguishes recurring subscription failures from failed additional-purchase checkouts. Trial expiry follows its own fallback-plan and retained-seat rules rather than automatically using the recurring-payment suspension path. See Billing and workspace trials for those distinctions.
An approved, governed AI administrative action can also reach the backend suspension operation. That route has its own permission and review controls. It is not an unrestricted assistant command, and this lifecycle guide does not establish that an AI-driven frontend journey is deployed.
Recovery can be manual or automatic¶
| Recorded condition | Recovery boundary |
|---|---|
| Administrator pause with administrator restoration allowed | An eligible current workspace administrator can request restoration after addressing the reason. |
| Billing suspension | Follow billing recovery and confirm that the payment has been verified and applied. The ordinary administrator Restore action does not bypass it. |
| Support or other pause without administrator restoration allowed | Contact authorized platform support. An administrator role alone does not override this restriction. |
The system records the type and permitted recovery separately from the reason's wording. A payment does not lift a manual or support pause. Do not diagnose the permitted recovery solely from a free-text reason, a preview button or the fact that a payment succeeded. Older pauses may require support because administrator restoration was not recorded for them.
Accepted subscription payment can restore a billing suspension. Certain qualifying plan or seat changes can also restore a billing suspension when their capacity and subscription conditions are met; an arbitrary purchase is not a universal recovery action. See subscription access and renewal for the current commercial rules.
Restoration returns the workspace to active status and clears its current suspension information. Eligible downgraded memberships may regain licenses when capacity allows. Inactive accounts, inactive memberships or branches, missing licenses, product permissions, access policies and insufficient commercial coverage can still prevent someone from working. Restoring the workspace does not approve waiting join requests or guarantee that every member returns.
Continuity and commercial expectations¶
Before pausing, agree which work is affected, who can verify recovery and how people will receive updates. Retain the reason and incident or change reference through the organization's normal process. A count displayed in a design or preview is illustrative; use actual workspace information for decisions.
Suspension and reinstatement are access operations. They do not by themselves establish a billing stop, refund, fixed recovery time, delivery of a notification to every member, or an automatic return to every previous entitlement. Review the actual subscription, commercial terms and capacity separately.
The backend uses cached workspace context as well as invalidation events. Different requests can briefly observe different states. An old page or a changed preview badge is insufficient evidence of success. Refresh the actual workspace state and verify a new product request after the operation.
Availability and unfinished work¶
The intended Final Screens provide active and suspended views, a required-reason pause confirmation and a restore confirmation. The current frontend renders those views from sample data. Confirming a pause or restoration changes only that page's local preview state; the presence of an API-client helper does not connect the page to the real operation.
Application delivery and a connected lifecycle workflow must be verified separately for the environment you use. No deployment receipt or completed real-workspace walkthrough has been established for this guide. Until the connected experience is available, use your organization's authorized support route for a real workspace change.
Read the task guide for preparation, expected results and recovery checks. Internal implementation and operational references remain in private documentation.