Responding to an approval
Where pending decisions land, what a card shows you, what you can change before approving, and what a rejection does.
Every pending decision, from either mechanism, ends up in the same place: your inbox in the console. Both mechanisms produce the same kind of card and take the same two answers.
Finding what is waiting
Three things point at it.
An email goes to the workflow's owner as soon as a run pauses. The subject reads "Approval needed" and names the workflow, and the body says whether the run stopped because the agent asked or because it reached a step that always needs a sign-off.
The Inbox item in the sidebar carries an amber count of everything waiting. The overview screen carries the same count as a card, with the age of the oldest item under it.
The inbox itself lists pending approvals and open failure reviews together, with filters to see one kind at a time. Only pending items appear. Once you decide, the item leaves the list and the record of the decision lives in the run's own timeline.
What a card shows
Pick an item and the detail pane shows what you are being asked.
An agent's own request leads with the sentence the agent wrote describing the action, and underneath, its reason for wanting a sign-off. A gate leads with the step's name and shows the values the gate was written to present, each in its own field.
Both carry the run's id and how long it has been waiting, and a link through to the full run so you can read what led here.
If the paused run has a browser session open, the card embeds the live view of it. You are looking at the actual page the run is sitting on, which is usually the fastest way to answer "is this the right thing to submit?".
Approving
The button is "Approve & send". The run resumes from exactly where it stopped.
A gate's fields are editable before you approve. What you leave in them is what the run records as having been approved, and that is what shows up in the run's timeline afterwards. Editing corrects the record of what you signed off. It does not rewrite the data the following steps work from, because a gate hands nothing on to them.
An agent's request is not editable. Those arguments belong to the agent that wrote them and are what it will re-execute on approval, so the platform refuses an edited version outright. If the action is wrong, reject it.
Rejecting
The button is "Reject", and next to it there is a note field. Use it. On a gate it asks "What should change?", on an agent's request "Why not?", and in both cases the text goes back into the run as the reason.
The note is optional, and it is sent only with a rejection. Typing a note and then clicking approve discards it.
What happens next depends on which mechanism stopped the run.
At a judgment step, the agent does not perform the action. It reads your reason mid-run and continues from there, so a rejection with "wrong address, use the billing contact" is worth far more than a bare no.
At a gate, the run stays stopped. The agent watching the run gets your reason along with what the gate showed you, and either corrects the presentation and asks you again or ends the run. A re-presented gate arrives as a fresh item in your inbox; the run's timeline is where you can see the earlier presentation and what you said about it.
Stopping the run instead
Sometimes the right answer is not a decision about this step. It is that the run should not be happening at all.
Open the run and press Stop. The confirmation dialog is honest about what that buys you: the run stops recording anything further right away, and work already sent to another system has been sent. A stopped run counts against nothing. It tells the platform nothing about whether the workflow is any good.
The dialog also offers, ticked by default, to stop the workflow's other running runs and pause the workflow itself. That default is deliberate. If you are stopping a run because you just found a flaw in the workflow, cancelling runs one at a time is a losing race against whatever is triggering them.
Afterwards it asks what went wrong, in one optional line. Whatever you write is attached to the run for whoever opens it later.
What you cannot do
Every approval goes to the workflow's owner. You cannot forward one, hand it to a colleague, require a second signature or set up an escalation for decisions that sit unanswered. One workflow, one accountable person.
Email is the only channel a pending decision is pushed to, and there are no notification preferences to tune: the settings screen shows you the address and nothing else. The console's notification log lists everything that was sent, in order, if you want to check what went out.
The run screen shows a waiting run and what is being approved, but it has no buttons on it. Decisions are made in the inbox.