Skip to content

Guide for approvers

“Approvals” /ws/approvals in the workspace is the approval queue. Switch the view with the scope control at the top.

  • mine — Waiting on you (you personally, or an approval group you belong to)
  • group — Steps addressed to an approval group you belong to
  • all — Every pending approval in the organization (view only)

all is there so you can see across the organization. The action bar does not appear on steps where you are not the approver. That restriction keeps the record of who approved something tied to the person who made the call, so when responsibility moves, an administrator changes the membership of the approval group.

Selecting a row opens a record on the right. The record is split into six tabs.

  • plan — The execution plan to approve
  • form — The request form values
  • route — The approval route and each step’s state
  • audit — Audit events
  • grants — Items issued from this request
  • related — Other requests from the same requester

Use the action bar at the top to approve, reject, or return on the Web.

When you approve, reject, or return on the Web, the Slack approval card is updated to the same result. The reverse holds too. What you press in Slack lands on the Web record, a request is never processed twice, and the audit record, the plan-hash verification and the parallel-approval behavior are the same either way.

“Requests” /ws/requests is the whole organization’s list of requests. Filter by status or a keyword (title, requester name, or #id). Selecting a row opens the same record as the queue, and the action bar appears only for steps where you are the approver.

Approval requests arrive as cards in Slack DMs. A card carries the changes that will actually be executed when you approve, rather than the text of the request form:

  • The operation, such as create_user for a Google user
  • Cost impact, such as +¥1,360/month
  • Execution method, either automatic or a task completed by a person
  • The plan hash, which guarantees that the content you approve matches the content executed. The system does not allow an approved plan to be replaced afterward.

The plan hash is the thing you are approving. Change one character of the request and the hash changes with it, so something other than what you read and approved can never run as an approved plan.

  • ✅ Approve — Completes your action in one tap. The next approver is notified automatically, and execution starts once every required approval is complete
  • Reject… — Enter a reason, which is sent to the requester and retained in the audit record
  • ↩️ Return — Use this when the request can be approved after a correction. A description of the required change is mandatory, and the requester resubmits it as a new request with prefilled values
  • For cards sent to several approvers at the same time, everyone must approve before the request proceeds. If one person rejects, the request ends and the other cards are updated
  • Return for missing information or conditions that the requester can correct
  • Reject when the request should end because it is not acceptable in principle

When in doubt, return it. If there is any chance the requester can get it through with a correction, returning saves them from starting over and keeps the whole exchange on one thread in the audit record.

For parallel approval, one return moves the whole request to Returned and closes the other approval cards. Every resubmission gets a new plan hash. Review the corrected content again.

When a direct report declares “I am proceeding,” you can do nothing if it is acceptable, and the declaration is confirmed automatically after 24 hours. Select “🛑 Stop” and enter a reason only when the activity should not proceed.

Home on the Web lists all approvals waiting for you, and “Review and approve” jumps to the record in the approval queue. Items waiting longer than 24 hours also show up in the administrator’s observability. Clear them early.