Skip to content
Sencai.docs

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.

Raising a change request

Section titled “Raising a change request”

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. The page is a table with the columns Title, Type, Risk, Status, Requester, Planned and Updated. State tabs above it split the requests by where they stand - Needs review, Planned (approved), Drafts, Done (implemented) and Closed (rejected and rolled back) - and a search box (title or description) plus Type and Risk filters narrow the list. Click a row to open its detail drawer.

Review and approval

Section titled “Review and approval”

A request moves through explicit transitions, each triggered from the detail drawer:

Transition From → to Who
Submit for review Draft → In review Member or higher
Approve In review → Approved Admin or Owner
Reject In review → Rejected Admin or Owner
Mark implemented Approved → Implemented Member or higher
Roll back Implemented → Rolled back Admin or Owner
  • Reject and Roll back ask for a reason, and cannot be confirmed without one. The reason is stored with the request and shown in the drawer and in its history.
  • Approve asks you to confirm first; the approval is recorded under your name and cannot be undone.
  • You cannot approve your own request. If you raised it, the Approve button is disabled with a note that another approver has to approve it. The platform refuses it as well, whatever your role.
  • A draft can still be edited (Edit) and deleted (Delete) from the drawer until it is submitted.

Viewing a request’s detail

Section titled “Viewing a request’s detail”

The detail drawer shows the status, type and risk level, the requester, every timestamp that has been recorded so far - planned, approved, implemented, and rejected - along with the description, rollback plan, evidence link, the rejection or rollback reason, and (if it originated from an incident, see below) a link back to that incident. A History list at the bottom records each transition, who made it and the reason given. The action buttons change with the request’s current status, so you only see the transitions that are actually valid next.

Linkage to deployments and audit

Section titled “Linkage to deployments and audit”

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 vs. compliance approvals

Section titled “Change requests vs. compliance approvals”

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.

What’s next

Section titled “What’s next”