What is Power Automate?

Power Automate is Microsoft's low-code workflow automation platform, part of the Power Platform that ships alongside Microsoft 365. It connects apps, automates repetitive tasks, and orchestrates work across services — and because a useful slice of it is seeded into every Microsoft 365 licence, it's already running in your tenant. The question for an admin is rarely "should we adopt Power Automate?" It's "who has built what, and does any of it matter?"

The anatomy of a flow

A flow is a trigger plus actions. The trigger is the event that starts it: an email arrives in a shared mailbox, an item is added to a SharePoint list, a form is submitted, a timer fires at 07:00. The actions are what happens next: post a Teams message, start an approval, create a Planner task, write a row somewhere, call an HTTP API. Between trigger and actions sit conditions, loops, and branches — enough logic to express real processes without it being programming in the classic sense.

The reach comes from connectors — hundreds of them, covering the Microsoft stack (Outlook, Teams, SharePoint, OneDrive, Dataverse) and the wider world (SQL, Salesforce, ServiceNow, GitHub, Jira). A flow can span all of them in one sequence, which is precisely its power and precisely why it needs DLP policies around it.

The flow types

• Cloud flows run in Microsoft's cloud and come in three flavours: automated (event-triggered), instant (a button press, including buttons inside Teams and Power Apps), and scheduled (timer-driven). This is the bread and butter — the patterns, limits, and design habits are in the cloud flows deep dive.
• Desktop flows run on a Windows machine and drive the UI itself — keyboard, mouse, browser, legacy thick-client apps. This is Microsoft's robotic process automation (RPA) story, for systems with no API worth calling. Attended and unattended modes, machine management, and honest caveats in desktop flows and RPA.
• Business process flows are guided stage-by-stage rails inside model-driven Power Apps and Dynamics 365 — less automation, more choreography for humans.

Adjacent to all three, process mining analyses event data to show which processes deserve automating in the first place.

What Microsoft 365 includes, and where paid begins

The seeded rights follow the same line as the rest of the Power Platform:

• Included with Microsoft 365: cloud flows using standard, in-suite connectors — the SharePoint-approval, Teams-notification, mailbox-triage category. Most personal-productivity automation lives comfortably here.
• Premium (paid): premium connectors (SQL, HTTP, Dataverse, most third-party enterprise systems), on-premises gateways, and unattended desktop flows. Licensed per user, per flow/process, or metered pay-as-you-go.

The distinction that catches organisations out: a flow is cheap to build and free to depend on — until someone adds one premium connector and the process now has a per-user or per-process price tag. The model has been reshaped several times, so check the current terms before scaling anything out; the wider arithmetic is in Power Platform licensing explained.

Run limits exist

Seeded licences also carry throttles — daily API request allowances per user, action limits, and slower queues for lower licence tiers. A flow that processes ten items a day never notices. A flow someone points at a 40,000-row list will. When a "working" flow starts failing intermittently under volume, licensing throttles are the first suspect, and error handling is the discipline that makes the failure visible instead of silent.

The governance reality

Power Automate is the most-built and least-inventoried thing in most tenants. Three habits keep it sane:

1. Environments — makers experiment in the default environment; anything a team depends on moves to a managed environment with an owner. See environments and governance.
2. DLP policies — decide which connectors may be combined before someone routes finance data to a personal cloud service, not after.
3. Service accounts for shared flows — a flow's connections run as the person who created them. The classic failure: a department's critical automation dies the day its author's account is disabled during offboarding. Business-critical flows belong to a service account, not a person.

That last one deserves repeating, because it is the single most common Power Automate incident in real tenants: flows die with their owners. Inventory the flows that matter and re-home them deliberately.

Where it fits

Power Automate is the glue layer of Microsoft 365: approvals that happen in Teams instead of email chains, notifications when documents change, mailbox-driven ticket creation, scheduled reports nobody has to remember to send. For a one-off task, a script may be simpler; for anything event-driven, recurring, or handed between people, a flow is usually the right first reach — provided the governance habits above arrive before the hundredth flow does, not after.