Approve control

An Approve control pauses a playbook until one eligible user approves or denies the request, or its deadline passes. The same run then continues through Approved, Denied, or Expired. Earlier actions are not repeated.

Use it before an action that needs a human decision, such as pushing a configuration after reviewing an agent’s analysis. For approval before connecting to a resource or transferring a file, configure a policy access approval.

Configure an Approve control

Open a playbook in Automation Studio. Add Approve from Control and connect the preceding step to its input.
Select the control and optionally set its Label to describe the decision.
Open Bindings → Edit to name any event fields or earlier results needed in the request. See Set up bindings.
Click Edit beside Title template and Message template. Use the Jinja editor’s Available Variables, then click Apply in each editor.
Select Approver roles and set Expires after and Unit.
Optionally enable Send email.
Connect Approved, Denied, and Expired to their next steps, then save the playbook.

Settings

Setting	Purpose
Bindings	Variables available to the title and message templates. Each control has its own bindings.
Title template	The request title in the notification list and details modal, and the email subject. It must render to non-empty, single-line text, up to 2,000 characters.
Message template	The explanation shown in the details modal and reused as the email body. It must render to non-empty text.
Approver roles	One or more roles whose members may decide. One eligible member of any selected role is enough; approval from every role is not required.
Expires after / Unit	Time allowed to decide, starting when execution reaches this control. Default: 24 hours. Allowed range: one minute to 30 days.
Send email	Optional notification to eligible users. Disabled by default. Requires configured SMTP and enabled application email notifications. The top-navigation inbox is always available.

Example: ask for review of an analysis

Place Approve after Run Agent → Success. In its bindings, add Run Agent → Agent response as analysis. Set the title to:

Review the proposed change

Set the message to:

Please review this analysis before allowing the next step to run.

{{ analysis }}

Approve to continue, or deny to stop the change.

Connect Approved to the action that performs the change. Leave Denied and Expired unconnected to end the run with a failure, or connect them to actions that handle those outcomes.

Title and message are rendered once when execution reaches the control. The modal and email use that recorded text, so later playbook edits do not rewrite a pending request. Text is displayed literally; HTML is not executed. Each reached Approve control creates a separate request with its own deadline. If a template cannot render to a valid title or message, the run fails without creating a request; inspect the run and correct the templates or bindings.

What each output does

Output	Selected when	If unconnected
Approved	An eligible user approves before the deadline.	Run completes successfully.
Denied	An eligible user denies before the deadline.	Run completes as Failed.
Expired	The deadline passes without a decision.	Run completes as Failed.

The decision selects the next branch independently of an earlier action’s success flag. The control forwards its incoming data unchanged, so downstream bindings can still use earlier results. A successful action on a connected Denied or Expired branch can complete the run successfully. A Switch alone preserves the current outcome.

Respond to a request

Open the message icon in the top navigation to show Approvals.
Use To review for pending requests you can decide, or My requests for your own requests and their status.
Open a request and read its title, message, scope, requester, and deadline.
Optionally enter a comment of up to 2,000 characters, then choose Approve or Deny. Opening the request never decides it.

You must belong to a selected approver role. For a request concerning a resource or location, you also need the relevant resource-read scope. Membership and access are checked again when you respond. You do not need access to Automate to decide, and administrator status does not bypass these eligibility checks. An eligible user may approve an automation run they initiated.

For a resource event, eligibility uses the resource’s current location. If the resource was deleted, its recorded location is used when that location still exists; otherwise unrestricted resource-read access is required. Requests concerning a location use that location’s scope. Global events without a scope require approver-role membership only.

Once anyone decides, the request leaves every eligible user’s To review list. If another person responds first, or the deadline passes, the modal refreshes and prevents another decision. My requests keeps the requester’s completed requests while their evidence is retained. An email link can still open a recorded decision when you remain eligible; sign in through the normal login flow if prompted.

The inbox refreshes when opened, after reconnecting, when returning to the browser, and periodically while the page is visible. It remains available across page reloads and Core restarts.

Monitor and cancel a waiting run

Open Automate → Runs and filter by Waiting for approval, or inspect automation requests in Review → Approvals. The run remains Waiting for approval until execution resumes. Continuation queued means a decision is saved and the run is waiting to resume.

In run replay, select the Approve control. Its Inspector shows the recorded title, message, selected roles, deadline, decision, deciding user, and optional comment. It can also show eligible-user counts and email delivery evidence. These management views require app.automation.read; they do not grant the right to approve.

Users with app.automation.write can cancel a waiting run while its request is still undecided. Cancellation takes no output branch and skips the remaining steps. A saved decision cannot be replaced by cancellation.

A referenced role cannot be deleted while a saved playbook, including a disabled one, or unfinished run uses it. Remove the role from saved controls and finish or cancel affected runs first. Completed run history does not block deletion.

Delivery, recovery, and history

Email delivery does not determine whether the request exists. If no email arrives, check the top-navigation inbox. The Inspector can show sent, failed, skipped, or unknown deliveries. Unknown means sending was interrupted and delivery could not be confirmed; it is not retried automatically. Email details can expire before the approval evidence itself.

A restart preserves undecided requests and their deadlines. If a restart interrupts resumed execution, the run can fail to avoid repeating actions whose effects are uncertain. Inspect a failed run before starting new work.

Recorded decisions survive later playbook edits or deletion and remain subject to retention. See Review → Approvals for historical access and cleanup, and Runs for replay details.

Permissions

Configure the control: app.automation.write and the Automation license feature.
Inspect automation run and approval history: app.automation.read.
Approve or deny: membership in a selected approver role and the applicable resource-read scope. Automation management permissions are not required.