Currently, once a Change Request (CR) is rejected or resolved as failed, it moves to a non-mutable status and cannot be approved or reopened via the UI or API. If the rejection was made in error, or the CR failed due to a platform-side issue, the only path forward is submitting a brand new CR and running it back through the full approval process.

For customers with formal internal change management processes, this creates friction when a mistaken rejection needs to be corrected quickly, since re-running an approval cycle can take significant time and blocks production changes in the interim.

Request: provide a supported way to recover from an incorrectly rejected/failed CR without requiring a full new submission and re-approval cycle. Options could include:

Allowing a rejected/failed CR to be reverted to a "requested" or "scheduled" state (with appropriate audit trail/permissions)

A dedicated recovery/override endpoint or workflow for this scenario, separate from the standard approval flow

Guidance or tooling for "cloning" a previously approved CR so it can be fast-tracked through approval

Context: the current non-mutability rule exists because resolving a CR (approve or reject) unblocks further changes to the underlying flag, so reopening an old CR risks inconsistency with the flag's current state. Any solution should account for this and avoid introducing state conflicts.