Approve, activate, and retire a release

Move a reviewed configuration into use, verify its state, and manage a replacement or rollback. A release fixes the asset versions used by a workload in an environment.

Before you start

Select the correct workspace and open Assure → Releases. Confirm the workload, environment, release identifier, and current state before any action.

You need the permission for the specific action: viewing, recording approval, activating, and rollback or retirement are separate responsibilities. The page shows only applicable transitions and disables actions you cannot perform. Follow your organization’s release responsibilities and change window.

Prepare and review

Prepare a draft release with the intended asset versions and configuration.
Inspect Bindings, Evaluations, Policy, and readiness information. Resolve missing requirements and check that evidence matches the candidate.
Select Submit for review and confirm that the release is Review ready.
Have an authorized reviewer record the approval decision. The release creator cannot approve their own release.

An approval decision is evidence retained in Approvals. Recording Approve there does not itself change the release to Approved or Active. A rejection decision also does not itself change the lifecycle state.

Approve and activate

Check the recorded approval and any required evaluation or policy conditions.
Select the release-level Approve action when it is available. Confirm the state becomes Approved.
Before selecting Activate, recheck the environment and workload readiness. Activation makes this release the workload’s active configuration in that environment and supersedes the previously active release there.
Select Activate, then confirm that the state is Active and that the intended release is shown on the workload.
Check the workload’s readiness and monitor the resulting runs through your organization’s normal release checks.

An active release does not guarantee that every execution will succeed. Runtime permissions, resource limits, external-service availability, and required human decisions can still affect a run.

Stand down, restore, or retire

These actions affect service availability or the configuration used for future runs. Read the confirmation before proceeding.

Action	Consequence and check
Stand down	Moves the release to Superseded. It can be reactivated later; standing down does not itself select a replacement. Check the workload before expecting more successful runs.
Reactivate	Restores a superseded release’s configuration and supersedes the currently active release. Confirm the workload and environment, select Reactivate, then verify the restored state and runtime readiness.
Retire	Permanently retires the release. It cannot be reactivated. Use it only when the release should no longer be an available rollback candidate.

Rollback restores the selected release’s bound configuration. Current governance and readiness requirements still apply, and rollback does not undo external actions or delete evidence from earlier runs.

If a transition fails

Problem	What to do
An action is missing or disabled	Check the current state and required permission. Ask the responsible administrator rather than using another person’s account.
Approval is required	Confirm that a valid independent approval exists in Approvals. Recording a decision and applying the approval transition are separate steps.
Readiness or activation is blocked	Read each requirement. Resolve missing assets, approved model configuration, service-lane binding, connection, or human oversight with its owner.
The release changed during your work	Refresh and inspect its current state and history before trying another transition.
A request has an uncertain result	Check the release and workload before repeating it. Do not assume that a failed response means the state change failed.

Investigate runs, test a replacement, or review evidence and governance.