# Organisation closure and reactivation

Understand scheduled closure, export access, API blocking, and reactivation boundaries.

Organisation closure is an owner-only lifecycle for team organisations. Personal organisations cannot
enter it. Business and manual-billing organisations require support assistance.

Owner initiation can be disabled while private-beta offboarding remains gated. Enforcement of an
existing lifecycle state is unconditional.

## Before scheduling closure

Confirm the exact organisation and review:

- Current billing and paid term.
- Accepted members and ownership.
- Projects, environments, flags, and credentials.
- Application dependencies and safe defaults.
- Required configuration or audit retention.
- The deadline shown by the console.

Closure is an organisation-wide operational action, not a substitute for archiving one project.

## Lifecycle states

| State             | Console and API behaviour              | Owner action                          |
| ----------------- | -------------------------------------- | ------------------------------------- |
| Active            | Normal operation                       | None                                  |
| Closure pending   | Fully operational                      | Cancel where supported                |
| Scheduled closure | Fully operational until effective date | Cancel or prepare export              |
| Export window     | Ordinary routes and keys blocked       | Export or reactivate where supported  |
| Deletion pending  | Access remains blocked                 | Reactivate only where still supported |

An unpaid eligible organisation can move from active to closure pending and scheduled closure. A paid
self-serve organisation remains operational through its paid term before the export window.

## Export-window enforcement

When the export window becomes effective, ordinary organisation routes are replaced by the focused
offboarding page.

Existing runtime, client, and management keys return `403 WORKSPACE_OFFBOARDING`. The error name remains
stable for technical compatibility although customer language uses Organisation.

Do not rotate keys or change scopes in response. The owning organisation lifecycle is the enforcement
boundary.

The owner-only export window lasts for the period shown in the console. Deletion pending follows when
the window expires or lifecycle advances.

## Export expectations

Export generation and final physical deletion are separate platform processes. Do not assume every
internal billing, audit, security, or operational record belongs in a customer export.

Retain independent copies of critical application configuration before the deadline. Contact support
when an expected export cannot be produced or retrieved.

## Reactivate

Owners can reactivate during supported pre-deletion states from the offboarding surface. An eligible
self-serve billing event may also reactivate the organisation.

Reactivation restores organisation access, but it does not replay requests that failed during blocking.
Applications must retry hosted work or refresh snapshots after access returns.

After reactivation:

1. Open the organisation and verify projects.
2. Test a safe runtime request.
3. Confirm snapshot refresh health.
4. Review key status and automation schedules.
5. Reconcile work skipped during the blocked period.

## Failure and support cases

- **Closure action is unavailable:** initiation may be gated or the plan may require support.
- **Every valid key returns `403`:** inspect lifecycle and `WORKSPACE_OFFBOARDING`.
- **Reactivation succeeded but jobs failed:** retry them; requests are not replayed automatically.
- **The owner cannot access ordinary routes:** use the focused offboarding page.
- **Export is incomplete:** compare documented scope and contact support before the deadline.

Related pages: [Organisations](/docs/platform/organisations),
[Plans and billing](/docs/administration/plans-and-billing), and
[Errors and fallbacks](/docs/evaluate/errors-and-fallbacks).