Skip to content
Sencai.docs

Approvals

The approval queue is where high-risk, high-blast-radius actions wait for a human decision before they run - a request carries what it would do, how many resources it would touch, and an estimated cost impact, and it sits pending until someone with the right role approves or rejects it.

Find it at Compliance & Audit → Approvals in the app (/gravity/approvals).

Which actions require approval

Section titled “Which actions require approval”

Not every action goes through this queue - only ones flagged as high-blast-radius, based on what they’d affect (how many resources, what kind of change) and their estimated cost impact. Every pending request has a 4-hour expiry window - it doesn’t sit open indefinitely waiting for a decision. An approval request carries:

  • The action being requested, with a human-readable label
  • The requester
  • An estimated cost delta (increase or savings), where Sencai can compute one
  • A blast radius - how many resources would be affected, and a short description of the estimated impact
  • An expiry countdown - a pending request isn’t open-ended; it expires if nobody acts on it in time

Requesting and reviewing

Section titled “Requesting and reviewing”

Pending and History tabs on the main Approvals page show what’s waiting for a decision and what’s already been resolved. From the pending list you can approve or reject inline, or open the full detail view (/gravity/approvals/<id>) for more context before deciding.

The detail view adds:

  • A dry-run preview - you can trigger a dry run of the pending action and see its result before approving, where the action type supports one
  • The full blast radius breakdown, including affected resource types
  • Cost impact, with an estimate of the monthly change
  • A rollback plan, listed as concrete steps, if the action has a defined way to undo it

Approving requires confirming in a dialog that repeats the blast-radius summary, so the decision isn’t a single accidental click. Rejecting requires a written reason, which is stored with the request and shown in its history.

Approval policies

Section titled “Approval policies”

There’s no separate, editable “who can approve what” policy screen in this section, and no role floor beyond ordinary membership - any member of the organization the request belongs to can approve or reject it, not only Owners or Admins. If your organization needs approvals restricted to a smaller group of people, that’s a process decision to make internally (for example, agreeing that only certain team members act on this queue), not something the app enforces for you today.

Delegation and expiry

Section titled “Delegation and expiry”

Every pending request carries an expiry time, shown as a countdown that turns from green to amber as it gets close, and to a plain “Expired” state once it passes. There’s no delegation mechanism on this screen (assigning a specific approval to a specific other person) - any member of the organization can act on any pending request belonging to it.

The audit record

Section titled “The audit record”

Every approval decision - who approved or rejected, when, and (for a rejection) why - is recorded and forms part of your organization’s audit trail, the same one the NIS2 evidence timeline draws from.

Approvals vs. operational change requests

Section titled “Approvals vs. operational change requests”

Approvals in this section are specifically about gating one proposed action before it runs. That’s a different mechanism from operational change requests, which track a broader change management process (planned maintenance, coordinated rollouts) rather than gating one specific in-the-moment action. If you’re looking for a change management workflow rather than an approval queue, that’s the page you want.

What’s next

Section titled “What’s next”