Automation Task Approvals

Approval flow adds a controlled pause before an automation task starts. When approval is required, a run is created in a pending state and no workflow steps are queued until the approval rule is satisfied.

Required approvers must approve before execution starts. Optional approvers can approve, but are not required. Any rejection from a configured approver stops the run.

When to Use Approval Flow

Use approval flow for tasks where execution should be reviewed before any step changes systems, triggers integrations, or touches production resources.

• High-impact maintenance actions, service restarts, or deployments.

• Published self-service tasks where end users can request execution.

• Scheduled or manual operations that should not start without operator review.

• Certificate, application, or infrastructure workflows where a failed or mistimed run has operational impact.

Approval States

When a task requires approval, execution moves through these states:

Pending approval: The run exists, approvers can review it, and no task steps have been queued.

Approved: The approval rule is satisfied. AZExecute queues the initial task steps automatically.

Approval rejected: An approver rejected the run. No automation steps are queued and the run is stopped.

Required and Optional Approvers

Approvers can be individual tenant users or tenant groups. Each approver target can be marked as required or optional.

Required approvers: Every active required approver target must approve before execution continues.

Optional approvers: Optional approvers are allowed to approve or reject, but their approval is not required to start execution.

Any rejection stops the run: A rejection from any configured approver, required or optional, rejects the run.

Only optional approvers: If no required approvers are configured, one approval from any active configured approver is enough to start execution.

Optional does not mean informational only. Optional approvers do not block approval by staying silent, but they can still reject while the run is pending.

Group Approvers

A group approver represents the active members of the configured tenant group. Group membership is evaluated when approval eligibility is checked.

• Any active member of a configured group can approve or reject for that group target.

• If a required group has no active members, it cannot contribute an approval until membership is fixed.

• The approval queue shows active member counts so operators can spot empty groups before relying on them.

Tenant Admin Override

Tenant admins can see all pending task approvals for the tenant and can approve or reject runs even when they are not configured as an approver.

• The home page approval queue shows tenant-wide pending approvals for TenantAdmin users.

• Task-specific approval queues show pending runs for that task and allow TenantAdmin override decisions.

• Override decisions are recorded as approval decisions for the run.

Where Approvals Appear

Home page: Shows pending approvals that require attention. Tenant admins see tenant-wide pending approval runs.

Task detail page: Shows the approval queue for the current task above the task tabs, so it remains visible regardless of which tab is open.

Expanded run details: Shows who requested the run and which users or groups are configured as approvers, including each approver's current status.

Recommended Patterns

• Use at least one required approver for production-changing tasks.

• Use optional approvers for teams that should be able to intervene, but should not block the task by being unavailable.

• Prefer groups for operational teams and individual users for explicit ownership or segregation-of-duty requirements.

• Avoid configuring only optional approvers unless any one approver should be allowed to release the run.