Microsoft 365 Automation Architecture: Where PowerShell, Graph, Azure Functions and Logic Apps Fit

I've written a lot on this site about automating Microsoft 365 and Intune with PowerShell and Graph. Almost none of it addressed a question that matters just as much as the script itself: where does this actually run once you're done writing it? A script sitting on your laptop, a scheduled Azure Automation Runbook, an Azure Function, and a Logic App can all technically call the same Graph endpoint. They are not interchangeable, and picking the wrong one is a common, quiet source of automation that works in testing and quietly stops working in production.

The Four Tiers

Each one exists because the others genuinely don't fit its job well. Here's why, one at a time.

PowerShell: Where Everything Starts

This is the tier this whole site's automation series has focused on: a reusable framework with proper auth, retry, and logging, a cookbook of real tasks, and the maturity ladder a script climbs to become production-ready. All of that is genuinely necessary groundwork. None of it answers where the script actually lives once it's done.

Azure Automation Runbooks: The Natural Next Step

This is usually the first stop once a script needs to run without a human present. A Runbook is that same PowerShell script, running on a schedule or in response to a webhook, in Azure, with no VM for you to patch or maintain. Authentication works exactly the way I've covered for managed identities, no secret to rotate, no certificate to manage.

Azure Functions: When the Trigger Is an Event, Not a Clock

This is the tier people reach for when the actual requirement isn't "run this every night," it's "run this the instant something happens": a new row in a database, a message landing in a queue, an HTTP call from another system. Functions support PowerShell directly, alongside C#, Python, and others, and scale automatically with the number of events firing.

The real numbers matter here, and they're easy to get burned by:

For PowerShell specifically, -AsJob on cmdlets that support it lets a Function parallelise multiple Graph calls within its own execution window instead of running them strictly sequentially, useful when a single event needs to touch several objects at once.

Logic Apps: When People, Not Just Systems, Are Part of the Flow

Logic Apps is a genuinely different tool, not just a no-code version of a Function. It's a visual, connector-driven workflow designer with over 200 prebuilt connectors, and it's the right choice specifically when a workflow needs to wait on a human, an approval step, a review, someone confirming an exception, or coordinate several different systems in a way that's easier to see as a diagram than read as code.

One real, structural limitation worth planning around: Logic Apps is cloud-first and cannot reach on-premises resources directly. If a workflow needs to touch an on-prem system, that step needs an on-premises data gateway or a different tier entirely.

The Decision Framework

A Worked Example Using All Four

A real new-hire onboarding pipeline, end to end, rarely lives in just one of these tiers:

Four tiers, each one doing the specific job it's actually good at. Building this entire pipeline as one Azure Function would mean fighting the timeout on the approval wait. Building it entirely as a Logic App would mean pushing complex Graph logic into a visual designer that fights back once the logic gets non-trivial. Building it entirely as PowerShell scripts would mean someone manually watching for the HR webhook because nothing was actually listening for it.

Choosing the Right Tier Is the Architecture Decision

The script quality, the auth pattern, the retry logic, all the mechanics covered elsewhere in this series, matter just as much regardless of which tier hosts the final result. But a perfectly hardened script deployed to the wrong tier still fails, just later, and more confusingly, than a mediocre script deployed to the right one. Match the trigger shape, schedule, event, or human approval, to the tier built for it, and the rest of the engineering actually gets to matter.

Which tier does most of your own M365 automation actually live in? I'd guess Automation Runbooks are still the default for most teams, mainly because it's the one people learn first, not necessarily because it's the right fit for every job. Drop a comment below with yours.