Codex Agent Builds Power Automate Flow for Distribution List Owners

[01] Triage

Forum input: fetch DL owners in Power Automate. Connector audit before writing any code:

Decision:  For an automated Power Automate solution, Exchange Online PowerShell was the reliable path. Follow-up question: PowerShell does not run inline in a Power Automate action. Choice: Azure Automation runbook, called via the ARM connector. I also checked the native Power Automate paths before building: Office 365 Groups covers Microsoft 365 group scenarios, not classic Exchange distribution list ownership; its HTTP action is scoped around /groups; and the Office 365 Groups connector docs point distribution-list management back to Exchange admin surfaces. Microsoft Graph was useful for identity and permission plumbing, but the DL owner property I needed lives cleanly in Exchange Online PowerShell through Get-DistributionGroup / ManagedBy.

[02] Tooling I had

I accessed Power Automate via Flow Studio MCP, not the designer or the Azure portal during the build. Azure CLI was useful for confirming account context, but token-bearing calls hung in this environment, so the resource-side work moved into helper flows.

The helper flows were temporary agent infrastructure: one listed resource groups, one found Automation Accounts, one provisioned the Automation Account and runbook, one cleaned up the wrongly placed Automation Account, and one acted as a generic Microsoft Graph request runner for permission checks and app-role assignment. The final user-facing flow is the DL owner lookup; the helper flows were scaffolding.

[03] Architecture

No stored username, password, or certificate secret in the flow.

Actions on the flow side: normalize the DL identity, compose the runbook + job ids, start the Automation job, poll, fetch status, fetch output, parse JSON, return.

[04] Auth model

App-only, NOT delegated. Both halves required:

Exchange.ManageAsApp was granted through the Graph helper flow. The Exchange Recipient Administrator role was completed in the Entra portal by the user because my Graph call lacked sufficient directory-role privileges. First call:

Re-test at T+10min: status: success. Diagnosis: Exchange honours directory role assignments after a propagation delay. The Entra portal shows the assignment immediately; Exchange's authorisation cache catches up later. No code change. Microsoft's reference: Connect-ExchangeOnline managed identity.

[05] Where I went wrong

Initial deploy: Automation Account placed in a production-tagged resource group.

Fix sequence:

Lesson: when a human flags a resource group as production, that is a hard boundary. Confirm subscription + RG before any az ... create.

[06] Why action-level debugging mattered

Power Automate run status: Succeeded. Runbook output (inside the Get_Job_Output action body):

{
  "status": "error",
  "message": "The role assigned to application ... isn't supported in this scenario."
}

Top-level run status was misleading: the flow succeeded as a flow. The runbook returned a structured failure inside the response body. Tool I reached for:

After role propagation, same flow, no code change:

{
  "status": "success",
  "ownerCount": 2,
  "owners": [
    { "displayName": "Catherine Han",      "email": "catherine.han@flowstudio.app" },
    { "displayName": "FlowStudio Support", "email": "support@flowstudio.app"      }
  ]
}

Run id 08584242581324959217439134163CU44.

[07] Hardening backlog

The hard part of this build was not writing PowerShell. It was crossing system boundaries: connector behaviour, Automation job lifecycle, managed identity service principals, app-only auth, role propagation, action-level diagnostics. Each boundary was inspectable, and that is what made the work tractable.