Understand workflow approvals

Why use workflow approvals

Enterprise automation often involves actions that require human judgment before they run. Workflow approvals give your organization control over automated processes at key decision points.

Use approval steps when a workflow includes:

• Destructive changes, such as deleting resources or modifying production environments
• High-cost actions that affect budgets or resource allocation
• Security-sensitive operations that grant or revoke access
• Irreversible modifications that cannot be rolled back after execution
• Task agent steps that generate recommendations or take actions requiring human verification before the workflow continues

Review and decision points

Approval steps serve as review and decision points where human expertise shapes the workflow outcome.

Reviewing AI-proposed actions before execution: Place an approval step after a task agent step to review the agent's recommendations before the workflow acts on them. The approver can see the task agent step's output in the approval request context, evaluate whether the proposed action is appropriate, and approve or reject it. This pattern ensures that AI-generated decisions receive human validation before they affect production systems.

Providing human expertise in complex scenarios: Approvers can add notes when they submit a decision. Use this to capture expert reasoning, flag concerns for the workflow owner, or document why a particular action was approved or rejected. These notes are recorded in the approval audit trail and are visible in the execution viewer alongside the approver's name and timestamp.

Approval audit trails: Every approval decision is recorded with the approver's identity, the timestamp, and any notes. This information appears in the execution viewer on the approval step and is available for compliance review. For more information, see the "Approval information in the execution viewer" section.

How workflow approvals work

The approval process follows these steps:

1. An automation designer adds an approval step to a workflow in the workflow builder and configures it with a descriptive message that provides context for approvers.
2. The automation designer selects who can approve in the Approver users and Approver groups fields. If no approvers are specified, any user with the approval:decide permission can approve the request.
3. Optional: The automation designer sets a decision window that defines how long approvers have to respond, and selects the fallback decision (reject or approve) that applies if no one responds in time and the workflow continues past the failure. If no decision window is set, the step uses the system default.
4. The approval step defines two output paths: an approved path and a rejected path. Each path connects to different downstream steps.
5. When a running workflow reaches the approval step, the branch pauses and the system creates an approval request. The workflow run status changes to Paused and the approval step shows Waiting for approval in the execution viewer.
6. An approver reviews the pending request and submits a decision with optional notes. Approvers can access pending requests from the Approvals page in the sidebar, or from the approval panel that opens automatically in the execution viewer when a running workflow reaches an approval step.
7. The workflow resumes on the path that matches the decision. If the approver approved the request, the workflow follows the approved path. If the approver rejected the request, the workflow follows the rejected path.

All decisions are final. After an approver submits a decision, it cannot be reversed. To change the outcome, you must run the workflow again.

Approval request lifecycle

Each approval request moves through a defined set of states:

All terminal states (approved, rejected, expired, and cancelled) are permanent.

Decision window and fallback decision

You can configure a decision window to limit how long approvers have to respond. If no approver responds within the window, the request expires and the approval step fails.

What happens after the step fails depends on the On failure setting and the Fallback decision:

• If On failure is set to Stop workflow or branch on failure, the workflow stops at the expired approval step. The fallback decision is not used.
• If On failure is set to Continue on failure, the workflow continues and the fallback decision determines which path the workflow follows:
  • Reject (default) — The workflow follows the rejected path.
  • Approve — The workflow follows the approved path.

If you do not set a decision window, the step uses the system default of 1 day.

Approval permissions

Approval authority requires two conditions:

1. RBAC permission: The user must have the approval:decide permission. The admin role includes this permission at system scope. The project-admin and project-user roles include it at project scope.
2. Approver list membership: If the automation designer specified approver users or groups on the approval step, the user must be on one of those lists. If no approvers are specified, any user with the approval:decide permission can approve.

Both conditions must be met. A user who has the RBAC permission but is not on the approver list cannot approve the request. A user who is on the approver list but does not have the RBAC permission also cannot approve.

For more information about roles and permissions, see the additional resources at the end of this topic.

Batch operations

You can approve or reject multiple pending requests at once from the Approvals page. Select the pending requests you want to act on, then click Approve or Reject in the toolbar. You can add an optional note that applies to all selected requests.

Only pending requests that you have permission to decide on are selectable.

Approval information in the execution viewer

When you view a workflow run that includes an approval step, the execution viewer displays the following information:

• Waiting for approval status on the approval step while the request is pending.
• Paused status on the overall workflow run when no steps are actively running and all branches are either waiting for an approval decision or waiting for a time period.
• A Pending approval badge on the execution detail header, the Run history panel, and the Workflow Runs page.
• Color-coded branch handles on the execution graph: green for the approved handle and red for the rejected handle. A checkmark on the taken handle shows which path the workflow followed after the decision.
• The name, decision, and timestamp of the approver after the request is decided.
• Any notes the approver provided with their decision.

When a running workflow reaches an approval step, the execution viewer automatically opens the Review approval panel. If a workflow has multiple pending approvals, you can navigate between them using the pagination controls in the panel header.

Approval request context

When an approver opens an approval request, they can review the following information to make an informed decision:

• The approval name and message set by the automation designer
• The workflow name and a link to the workflow definition
• When the approval was initiated
• The output from the step that ran immediately before the approval step

Current limitations

The approval system has the following limitations in this release:

• Approvers must check the Approvals page or the execution viewer panel manually. In-app notifications and external notifications (such as email or Slack) are not available.