Enable, disable, state

An application has one of three states:

Enabled — the normal state. The application can request tokens.
Disabled — soft-stop. The application cannot request new tokens. Existing tokens it has issued remain valid until expiry; refresh attempts fail.
Deleted — gone. Hard-removed.

The state field is set once on creation (Enabled) and toggled freely between Enabled and Disabled. Delete is a separate action covered in Delete an application.

When to disable

An application is being deprecated; you want to verify nothing's calling it before deletion.
A team is decommissioning a service; you want to disable the credentials before scrubbing them from infrastructure.
A leaked secret is being investigated; disable while you triage; re-enable + rotate when clear.
A staging app is going stale; disable it while you decide whether to delete.

What disable does

New /oauth2/token requests with the application's credentials return unauthorized_client.
New /oauth2/authorize flows initiated against the application redirect with an error.
Tokens already issued by the application keep working until they expire — typically minutes for access tokens, days for refresh tokens.
Sessions that the application participated in are not auto-revoked. Users stay signed in until their session expires.

If you need new tokens to stop and existing tokens to immediately stop working: disable the application AND revoke its outstanding tokens. The Credentials tab on the application detail page has a "Revoke all outstanding tokens" action; the audit log records the bulk revocation.

What disable doesn't do

It doesn't change the application's client_id or client_secret. Re-enabling brings the same credentials back online.
It doesn't drop redirect URIs, allowed scopes, or configuration. Everything's frozen as-is.
It doesn't notify users. If your application is customer-facing, your team should communicate the planned outage independently.

Re-enable

Application detail → state chip (top header) → click → Enable. Or use the action menu.

The application starts accepting tokens immediately. Existing client credentials still work; the developers don't need to re-fetch the secret.

State + bulk operations

The application list lets you multi-select and bulk-enable / bulk-disable. Useful patterns:

Tag all deprecated apps with deprecated, filter, select-all, disable.
During a security incident, filter to a team's apps, select-all, disable; then re-enable individually as you confirm each is clean.

The audit log records bulk operations as N individual events, each with its own actor + timestamp + before/after state. The bulk action itself appears as a parent event linking them.

Avoid disable as a long-term parking lot

Disabled applications are records-of-things-no-longer-in-use. They pile up. Six months in, your applications list has 60% disabled rows and the active applications are hard to find.

Two ways to keep the list clean:

Tag disabled-but-not-yet-deleted apps with deprecated; filter them out by default in the list.
Set a quarterly review: anything disabled for > 90 days gets deleted (after a final check that no one's calling its client_id).

What if I disabled the wrong application?

Re-enable. Nothing's lost; the application's credentials still work. Disable is fully reversible.

If a customer-facing application was accidentally disabled and you re-enabled within a few minutes, the impact is one of: failed sign-ins during the window, or no sign-ins because everyone's already signed in. Apologise + post-mortem.