Skip to content

Change requests

Operations → Change Requests (/gravity/operations/change-requests) is a lightweight change-management flow for anything risky enough to want a second pair of eyes before it happens - infrastructure, configuration, code, network, database, or security changes.

Any organization member can create a change request with:

  • Title and description
  • Type - Infra, Config, Code, Network, Database, or Security
  • Risk level - Low, Medium, High, or Critical
  • Rollback plan - free text describing how to undo the change if it goes wrong
  • Planned at - a single date/time for when the change is expected to happen (there’s no start/end change-window concept - one timestamp is what’s recorded)
  • Evidence URL - a link to a PR, ticket, or runbook backing the change

New requests start as Draft on a Kanban-style board with four columns: Draft, Review, Approved, and Implemented. Each column header shows a live count, so you can see at a glance how many requests are waiting on review versus already implemented.

A request moves through explicit transitions, each triggered from its detail dialog:

TransitionFrom → toWho
Submit for ReviewDraft → ReviewMember or higher
ApproveReview → ApprovedAdmin or Owner
RejectReview → RejectedAdmin or Owner
Mark ImplementedApproved → ImplementedMember or higher
RollbackImplemented → Rolled BackAdmin or Owner

Rejected requests are shown in the Review column with a Rejected badge; rolled-back requests appear in Implemented with a Rolled Back badge, so the board keeps a record of both without a separate archive.

Clicking a card opens its full detail: status, type, risk level, and every timestamp that’s been recorded so far - planned, approved, implemented, and rejected - along with the description, rollback plan, evidence link, and (if it originated from an incident, see below) a link back to that incident. The action buttons available in the dialog change based on the request’s current status, so you’ll only ever see the transitions that are actually valid next.

A deployment record can carry a link back to the change request that authorized it, so a production deployment’s history shows the review it went through. Every transition on a change request - submitted, approved, rejected, implemented, rolled back, and by whom - is written to your organization’s audit log.

Auto-remediation rules that require manual review also create change requests automatically (title prefixed Auto-remediation:), landing in Draft with the matched incident and rule referenced in the description - so an automated match that needs a human still goes through this same board.

Only requests belonging to your active organization appear on the board - switch organizations in the app to see another organization’s change requests.

Change requests here are a general-purpose, informal review flow for anything your team wants to track before doing it - there’s no enforced gate stopping the underlying action from happening outside this board. Compliance → Approvals is a different, stricter mechanism: a specific set of high-blast-radius platform actions that are actually blocked until approved, with the approval itself becoming part of your compliance evidence. Use change requests for your own team’s change-management process; use the Approvals queue when you’re relying on Sencai to actually enforce the gate.