Azure AI Foundry Workflow HITL: Shared Approval with Same Execution Context, RBAC, or External Approval Required?

Question

Azure AI Foundry Workflow HITL: Shared Approval with Same Execution Context, RBAC, or External Approval Required?

Shivam Namdeo 0

Hi Community,

I have a question regarding Azure AI Foundry Workflow HITL (Human-in-the-loop) approval.

If a user (for example, Shivam) starts a workflow using any execution method such as Playground, Preview, REST API, SDK, or external triggers, and the workflow pauses at an HITL step:

Can another user (for example, Sid) open the same paused workflow execution within Azure AI Foundry Preview (or any built-in Foundry experience) and approve/reject it with the same execution context?
Does Azure AI Foundry provide any built-in shared approval mechanism with RBAC/delegated approvers?
Or is an external approval mechanism required? For example, starting a conversation/workflow through REST API / SDK maintaining the same execution context, and invoking the workflow again to capture the human decision and resume execution through another service.

I am specifically evaluating this pattern for a Terraform automation workflow where human approval is required before proceeding with the next step.

Thanks!

Manish Deshpande 7,815 Reputation points Microsoft External Staff Moderator

2026-08-07T19:37:05.2033333+00:00

Hello @Shivam Namdeo

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Shivam Namdeo 0 Reputation points

2026-08-08T02:33:45.8366667+00:00

HI @Manish Deshpande
Thanks, this clarifies it. We’ve already added a Logic App for Teams-based approval and are starting another modular workflow for the same use case you described. We’ll follow the external state pattern using the responses we receive from the v1/responses API.

1 answer

Your answer

Manish Deshpande 7,815 Reputation points Microsoft External Staff Moderator

2026-08-07T19:37:05.2033333+00:00

Hello @Shivam Namdeo

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Shivam Namdeo 0 Reputation points

2026-08-08T02:33:45.8366667+00:00

HI @Manish Deshpande
Thanks, this clarifies it. We’ve already added a Logic App for Teams-based approval and are starting another modular workflow for the same use case you described. We’ll follow the external state pattern using the responses we receive from the v1/responses API.

Answer 1

Hello @Shivam Namdeo ,

Good question to ask before building the pipeline rather than after the answer changes the architecture, and there's a timing factor you'll want to know about up front.

The short answers are no, no, and yes. But the useful part is the reframe behind them.

The key distinction: Foundry HITL is an execution-suspension mechanism, not an authorization mechanism. It pauses a run and resumes it when a decision arrives. It doesn't decide who is entitled to make that decision, and it doesn't record who made it. Once that lands, all three of your questions resolve cleanly.

Before the detail two things that affect your design decision

Both are documented and both matter for a production Terraform gate:

Foundry Workflows is in public preview. The docs state plainly: "This preview is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities."
Workflows is being retired on 1 December 2026. "Microsoft Foundry is retiring workflows on December 1, 2026. If you're looking to build new workflows, use Microsoft Agent Framework."

Importantly, this is not a capability removal. After that date the visual designer and in-portal workflow execution aren't supported, but "Foundry continues to run YAML-based workflow definitions when you deploy them as a hosted agent." Your orchestration logic carries forward — it's the portal authoring surface that goes away. Since you're building new rather than migrating, you can start on the supported target and skip a migration entirely.

1. Can Sid open Shivam's paused execution and approve it with the same context?

Not as a built-in Foundry experience. There's no shared approval queue, no "paused runs awaiting my approval" view, and no concept of an approval step belonging to a particular person.

At the API layer, resumption is a protocol operation against the same thread rather than a user action, so a second principal with sufficient project access can technically issue the resume call. But Foundry doesn't bind that decision to an identity — from the workflow's perspective, an approval arrived, not Sid approved.

I'd flag that plainly rather than present it as a workable route: for infrastructure automation, an approval with no attributable approver is an audit gap, not a UI inconvenience. It's the difference between a gate and the appearance of one.

2. Is there built-in shared approval with RBAC / delegated approvers?

No. Foundry RBAC is scoped at the account and project level — there's no per-agent, per-workflow, or per-step scope, so it structurally cannot express "only Sid may approve step 7." It governs who reaches the project at all. For reference, the documented requirement for creating and editing workflows is Contributor or higher on the project, which is already a fairly broad grant — not the fine-grained approver control you'd want gating terraform apply.

I'm not aware of any published roadmap for per-step approver assignment, so please don't plan around it arriving.

3. So is an external approval mechanism required?

Yes and this is Microsoft's documented guidance, not a workaround. Your instinct here is correct.

Microsoft Cloud Security Benchmark control AI-5, "Ensure human-in-the-loop", prescribes exactly your proposed pattern: "Design workflows using Azure Logic Apps or Power Automate that pause AI processes at critical junctures, routing outputs to human reviewers via secure dashboards with all actions logged in Azure Monitor for traceability," and "Protect review systems with encryption, implement strict access controls using Microsoft Entra ID, and deploy anomaly detection to prevent tampering or unauthorized access to approval processes."

AI-5 is rated criticality "Must have" and maps to:

User's image

The shape that works for a Terraform gate

Workflow reaches the approval gate and emits the interrupt.
Your approval service captures it and persists it durably — the run shouldn't be the system of record.
Notify the approver (Teams, Logic Apps, Power Automate).
Entra ID authenticates and authorises the approver. This is where your separation-of-duties rule lives, because Foundry can't enforce it.
Your service issues the resume call and records who decided, when, and against which plan output.

Given your requirements, I'd steer you toward one of these two:

Microsoft Agent Framework — the recommended target and the closest match to workflow semantics, via declarative YAML or code-first authoring, deployed as a hosted agent. Best if you want the orchestration in code alongside your pipeline.
Azure Logic Apps — if a visual designer is what you value. It's the documented migration path for exactly that preference, has a built-in approvals connector, and can call Foundry agents as steps. For a Terraform gate that mixes deterministic steps with an AI-reasoning step, this often fits better than it first appears.

Three implementation gotchas worth knowing now

Batched tool calls the one that would actually hurt you. A single model response can contain both approval-required and non-approval tool calls. Resolving the visible interrupt completes the whole batch per each tool's mode: a never_require sibling executes and streams its result even when the approval-required sibling is rejected. If a sibling touches infrastructure, a rejected approval won't stop it. Mark every state-changing operation as always-requiring approval and keep approvals granular rather than batched. Cancelling instead of resolving aborts the resume and clears queued approval state for the thread, so stale calls from that batch can't resurface later.

Run expiry. If you go near the raw agent function-calling path: "Runs expire 10 minutes after creation. Submit your tool outputs before they expire" — and that limit applies to total elapsed time, not individual function execution. Ten minutes is not a human-review window, especially for reviewing a Terraform plan. This is a concrete reason the durable external pattern isn't optional for you.

Don't let the run hold your approval state. Persist the pending approval in your own store keyed to the plan output, so a restart or expiry doesn't lose the decision or, worse, silently drop the gate.

One design suggestion

Consider gating on the plan artifact hash rather than just a boolean approve/reject. Approving "this exact plan output" rather than "this workflow step" prevents the plan from drifting between approval and apply, and it gives you the tamper-evident audit trail that the pure chat-based approval doesn't produce on its own.

If you share how you're triggering the workflow — SDK, REST, or a pipeline task — I'm happy to sketch where the approval service slots into a plan/apply sequence, including the Entra authorisation check and the Azure Monitor logging.

References

Thanks,
Manish.