Approvals
Approvals is the cross-automation inbox of work waiting on a person. Its heading reads Pending Approvals, and it lists every step, in every automation, that is currently parked waiting for someone to answer—an agent's question, a mid-workflow form, a step waiting to be resumed by hand. You do not have to know which automation stopped in order to find and answer it.
The navigation item carries a badge with the number of waiting steps, so a request that arrives while you are working somewhere else in the CMS is visible without opening the page.
What the table lists
Requests are listed newest first, so one that arrives while you are reading lands where you are already looking. The list refreshes itself as runs raise and settle requests—you never need to reload to see a new one.
| Column | What it shows |
|---|---|
| Run | The automation's name, linking to the run's workflow view, with the run number beneath it. A run started as a dry run is badged Dry Run here, because answering one is not the same act as answering a live request. |
| Step | What is being asked: the step's title, plus the label the step wrote for this particular request—the closest thing to instructions you get without opening the run. A step inside a loop also shows which pass is asking, which is often the only thing separating otherwise identical requests. |
| Waiting since | How long the request has been sitting, as a relative label. |
| Time left | A live countdown to the moment the request must be answered by. Hover it for the exact deadline. A request with no deadline shows an em dash. |
| A Respond button. |
Respond opens the step's own answer form in a popup over the list, and returns you here when you submit it—so you can work down a queue of requests without leaving the inbox. Which form opens is decided by the step itself, so a step type from any integration lands you on the right response surface.
When nothing is waiting, the page reads No approvals are waiting on you right now. A very large backlog is capped: the page shows the first 200 requests and says so beneath the table.
What the page does not do
The inbox only lists and links. Answering a request is done on the step's own response form, and the run resumes from there. A request can also be answered wherever else the step sent it—a Slack or Microsoft Teams message, for instance—and however it is answered, the inbox drops it. Two people can never answer the same request twice.
A request nobody answers within the Awaiting Input Timeout fails its step, and the run then behaves as it would for any other failure. The timeout is set in hours on the Nodes tab of the Settings page and can be overridden per automation.
See also
- Human in the loop—how a step pauses, where a request can be answered, and how long a wait may last.
- Monitoring and history—reading the run a request belongs to.