# Power Automate > Microsoft's automation tool that lives where your work already is (365, Teams, SharePoint): cloud flows, connectors and approvals, plus desktop RPA and its governance limits. --- # Power Automate If your company runs on Microsoft 365 - Outlook, Teams, SharePoint, Excel sitting in OneDrive - then Power Automate is the automation tool already sitting in the building. It used to be called Microsoft Flow, and a lot of people still call it that. It's the thing that fires when a form gets submitted, routes a document for approval, copies an email attachment into a folder, or pings a Teams channel when a row changes in a list. You don't go shopping for it. It comes bundled, and one day someone in ops realizes it's been there the whole time. This guide is for the person who lives inside Microsoft 365 and wants to stop doing the same five-click ritual forty times a day. You don't need to be a developer. You do need to be willing to think in terms of triggers and actions, and to learn where the tool helps you versus where Microsoft's licensing quietly puts up a tollbooth. We'll be straight about both, because the gap between "this is free with my license" and "this needs a premium add-on" is the single thing that trips up every new builder. The arc across the phases: first we cover **cloud flows** - the trigger-and-action model, the connector ecosystem, and why Power Automate dominates shops that already pay Microsoft. Then **connectors, approvals, and data** - the standard-versus-premium split that decides your bill, the built-in approval system that's genuinely good, and how flows talk to SharePoint and Dataverse using expressions. Finally **desktop RPA and governance** - Power Automate Desktop, which clicks through old apps that have no API, plus the licensing gotchas and the admin controls that keep a few hundred employees' flows from becoming a security mess. --- # Flows in the Microsoft World Every Power Automate flow is the same shape: **when this happens, do these things.** The "when" is a trigger. The "do" is a sequence of actions. That's the whole mental model, and once it clicks, the rest is learning which triggers and actions exist. A flow you build might be: *when an email arrives in this Outlook folder with an attachment, save the attachment to this SharePoint library, then post a message in this Teams channel.* One trigger, two actions. Power Automate watches Outlook for you, and when the email lands, it runs the rest top to bottom. ## The three kinds of cloud flow Cloud flows run on Microsoft's servers - you build them once, and they keep running whether your laptop is open or not. There are three flavors, separated by what starts them. | Type | What starts it | Example | |------|----------------|---------| | Automated | An event in some service | New file in SharePoint → notify a channel | | Instant | A button you press | Tap a button in the Teams app → log "I'm out sick" | | Scheduled | A clock | Every weekday at 8am → email a summary report | Most of what people build is automated - react to a thing happening. Instant flows are handy when you want a human in the loop pushing the button. Scheduled flows are your recurring chores: the Monday report, the nightly cleanup, the monthly reminder. There's a fourth thing people lump in - **desktop flows** for robotic process automation - but those click through apps on an actual machine and behave differently enough that they get their own phase later. For now, "flow" means cloud flow. ## Triggers and actions, concretely A **trigger** is the single event at the top of the flow. A flow has exactly one. "When a new item is created in a SharePoint list." "When a new email arrives." "When a HTTP request is received." The trigger also hands you data: the new list item, the email's subject and body, who sent it. That data flows downward. An **action** is a step that does something: send an email, create a file, update a row, call another service, post to Teams. You chain them. Each action can use the output of any step above it - the trigger's data, or the result of an earlier action. So step three can use the email subject from the trigger and the file name created in step two. Between actions you add logic: **conditions** (if the amount is over $500, do this branch, otherwise that one), **loops** (for each attachment, save it), and **scopes** (group steps so you can wrap error handling around them). It looks like a vertical flowchart in the editor, and that's what it is. ```mermaid flowchart TD T[Trigger: new SharePoint item] --> C{Amount > 500?} C -->|Yes| A[Start approval] C -->|No| B[Auto-approve + log] A --> N[Notify requester in Teams] B --> N ``` ## Connectors: the reason it exists A flow is only as useful as the things it can touch. Those things are **connectors** - pre-built bridges to a service. The Office 365 Outlook connector knows how to read your mail and send it. The SharePoint connector knows how to create, read, and update list items and files. There are connectors for Teams, Excel, OneDrive, Planner, Forms, Dataverse, and hundreds beyond Microsoft's own walls - Salesforce, Twitter/X, Dropbox, SQL Server, Jira, and more. Each connector exposes its own triggers and actions. The whole catalog runs into the hundreds, and that breadth is the real product. You're not wiring up APIs by hand - someone already wrote the bridge, you pick the trigger and fill in the boxes. There's a catch, and it's the most important thing to internalize early: connectors are split into **standard** and **premium**. Standard ones (Outlook, SharePoint, Teams, OneDrive, Excel) are included with most Microsoft 365 business plans. Premium ones (SQL Server, the generic HTTP action, Salesforce, custom connectors, Dataverse in many cases) need a paid Power Automate plan on top. We'll take this split apart in the next phase, because it decides what your automation actually costs. For now, know that the line exists. ## Why it wins in a Microsoft shop If your organization already pays for Microsoft 365, Power Automate is sitting in the license, integrated with the tools your colleagues already trust. That changes the math against a standalone competitor. - **It's already paid for** (at the standard tier). No new vendor, no new invoice, no procurement cycle. - **It already has your identity.** It signs in as you, through the same single sign-on, with the same security and compliance posture IT already vetted. A standalone tool means a new login and a new place your data lives. - **It speaks Microsoft natively.** SharePoint, Teams, Outlook, and Excel connectors are first-party and deep. The flow can reach the document library, the channel, the calendar - the places your work actually lives. - **IT can govern it.** Admins control it from the same console as the rest of 365 - who can build flows, what data can mix, which connectors are off-limits. That bundle is hard to beat inside a Microsoft house. The flip side: outside a Microsoft house, you're paying for an ecosystem you don't use, and a lighter tool may serve you better. Power Automate's strength is gravity - it pulls work toward where your work already is. The next phase is where that gravity gets real: connectors, approvals, and how flows read and write your actual data. --- # Connectors, Approvals & Data This phase is where you move from "I made a flow that pings Teams" to "I built something my team relies on." Three things matter: knowing which connectors cost extra, using the approval system Microsoft already built for you, and getting your flow to read and write real data - SharePoint lists, Dataverse tables - with a bit of expression glue. ## Standard vs premium: the line that costs money The single most common surprise for new builders is dragging in a connector, finishing the flow, hitting save, and getting told they need a premium license. So learn the split before you build. **Standard connectors** come with most Microsoft 365 business plans. The everyday ones: - Office 365 Outlook, SharePoint, OneDrive for Business - Microsoft Teams, Planner, To Do - Excel (Online), Forms, Approvals, Notifications **Premium connectors** need a paid Power Automate plan stacked on top of your 365 license. The ones that bite people: - SQL Server, and most third-party databases - The generic **HTTP** action - the moment you want to call any API that doesn't have its own connector, you've gone premium - Salesforce, Jira, and many other non-Microsoft business apps - Custom connectors (your own API wrapped as a connector) - Dataverse, in many licensing scenarios ```text RULE OF THUMB Staying inside Microsoft 365 (mail, files, lists, Teams)? → usually standard, included. Reaching out to a database, a raw API, or a third-party SaaS? → expect premium. ``` Microsoft has shifted its licensing over the years toward **per-user** and **per-flow** premium plans, and the exact names and prices change. Don't memorize a number - instead, before you build anything beyond plain 365, check what your tenant is actually licensed for. The connector picker flags premium connectors with a label; trust that flag and confirm with whoever owns the bill. A flow that works in the editor but can't run in production because nobody has the license is a classic, demoralizing trap. ## Approvals: the feature worth showing up for If you build one thing in Power Automate, make it an approval. The **Approvals** connector is genuinely well done and saves you from reinventing the most common business workflow there is: "someone requested something, a human needs to say yes or no." You add a **Start an approval** action. You pick the approver(s), write the title and details, and choose the type: - **Approve/Reject – First to respond:** any one approver can decide. - **Approve/Reject – Everyone must approve:** all of them have to sign off. - **Custom responses:** your own buttons, like "Approve / Send back / Reject." The approver gets a card - in Outlook, in Teams, or in the Power Automate app - with Approve and Reject buttons right there. They don't leave their inbox. Your flow then **waits** at that step. When the response comes back, the flow continues, and you branch on the outcome: ```mermaid flowchart TD R[Request submitted] --> S[Start approval to manager] S --> W{Outcome} W -->|Approve| Y[Update record, notify requester] W -->|Reject| N[Mark rejected, ask for changes] ``` The flow can sit paused at that approval for hours or days - that's normal and expected. You get the responses, the comments, and a timestamp recorded automatically, which is exactly what you want when someone later asks "who approved this and when?" ## Reading and writing your data Most useful flows revolve around a data store. In a Microsoft shop, that's usually a **SharePoint list** or a **Dataverse table**. A **SharePoint list** is a structured table living in SharePoint - columns, rows, types. It's where small teams keep requests, trackers, and inventories. The SharePoint connector gives you the bread-and-butter actions: *When an item is created or modified* (trigger), *Get items*, *Create item*, *Update item*, *Get item*. Build a request tracker as a list, trigger a flow on new items, route an approval, and write the outcome back to the row. That pattern alone covers a huge amount of real office work. **Dataverse** is the heavier option - a proper relational database underpinning the Power Platform, with relationships, security roles, and business rules. Reach for it when a SharePoint list stops being enough: thousands of rows, strict permissions, related tables that need to stay in sync. Note that Dataverse usually lands on the premium side of the license line, so factor that in. ## Expressions: the glue you'll eventually need You can build a lot by filling in boxes. But sooner or later you need to *compute* something - format a date, default a blank field, build a string, do a small calculation. That's **expressions**, written in a formula language (it's the same Workflow Definition Language under the hood, and it looks like spreadsheet functions). A few you'll reach for constantly: ```text utcNow() -- right now, as a timestamp formatDateTime(utcNow(),'yyyy-MM-dd') -- today as 2026-06-30 concat('Hello ', triggerBody()?['Name']) -- glue strings together coalesce(item()?['Owner'], 'Unassigned') -- fall back if blank if(greater(item()?['Amount'], 500), 'High', 'Low') -- inline decision ``` You add these in the same fields where you'd type plain text, via the expression editor. Don't go overboard - if a step is turning into a wall of nested expressions, that's a sign the logic belongs in a condition or a clearer set of steps. Reach for expressions to fill gaps, not to write programs inside a text box. Get these three down - the connector split, approvals, and reading/writing your data with a little expression glue - and you can build the bulk of what an office actually needs. The last phase is the other world: desktop RPA, for the old apps that don't have a connector at all. --- # Desktop RPA, Governance & Limits Cloud flows are great when the things you're automating have a connector. But plenty of business software doesn't - the ancient accounting program from 2009, the green-screen terminal nobody will touch, the website with no API. For those, Microsoft has a second tool with the same name: **Power Automate Desktop**. It's robotic process automation, or RPA, and it works by driving the screen the way a person would. ## What desktop RPA actually does A **desktop flow** automates the user interface directly. It opens an application, clicks the buttons, types into the fields, reads values off the screen, copies data between windows. You build it by recording your clicks or by dragging steps in the desktop designer - open this app, click that field, extract that table, type this value. The plain mental model: it's a very fast, very literal intern with no judgment. It does exactly what you taught it, in exactly the order you taught it. That's the strength - it can finally automate the legacy app that has no other way in - and the weakness, because anything that moves on screen can break it. Use desktop RPA when there's **no connector and no API**. If a connector exists, use the cloud flow - it's faster, sturdier, and doesn't depend on a screen. RPA is the tool of last resort, not the default. People who lead with RPA end up with brittle automations that snap every time a vendor ships a UI update. ## Attended vs unattended - and why it matters for the bill There are two ways to run a desktop flow, and the difference is mostly about licensing. | Mode | Runs when | Needs | |------|-----------|-------| | Attended | A person is signed in and watching the machine | A user-level RPA license; included in some Windows 11 / Power Automate scenarios | | Unattended | On a machine with nobody logged in, on a schedule, hands-off | An add-on (the unattended RPA license) - this is the expensive one | **Attended** is a person kicking off an automation on their own PC and letting it run while they grab coffee. **Unattended** is the dream - a bot machine churning through work overnight with nobody there. Unattended is also where the cost lands. The unattended capability is a paid add-on, and it's typically the single biggest line item in an RPA project. Microsoft has bundled some attended desktop usage with Windows 11 over the years, but unattended is the one you budget for. ## The licensing gotchas, plainly The licensing is the part that derails projects, so here's the short, no-nonsense version: - **Premium connectors aren't free.** Anything beyond standard 365 connectors needs a premium plan. (Covered last phase - it still applies the moment a desktop flow hands off to a cloud flow that calls something premium.) - **Unattended RPA is a separate, paid add-on.** Don't design an overnight bot before you've confirmed someone's paying for unattended. - **Plans and prices shift.** Microsoft has reshuffled per-user, per-flow, and "hosted process" RPA licensing repeatedly. Whatever number you read in a blog post is probably stale. - **Check your tenant, not the marketing page.** Before promising an automation, confirm what your organization is actually licensed for. The cheapest mistake is the one you catch before you build. ```text BEFORE you build an RPA project, answer: 1. Is there a connector/API? -> if yes, don't use RPA. 2. Attended or unattended? -> unattended = paid add-on, confirm budget. 3. Does it hand off to a premium connector? -> another license to check. 4. Who maintains it when the target app's UI changes? -> someone must own it. ``` ## Governance: when one flow becomes five hundred A single person's flow is harmless. Power Automate's real risk shows up at scale: a few hundred employees each building flows, and now sensitive data is flowing through automations nobody's tracking. This is where admins earn their keep, and where a builder should understand the guardrails they're working inside. **Environments** are the containers. An environment is a separate space - Default, plus ones admins create for a team, a project, or to split production from testing. Flows, connections, and Dataverse data live inside an environment, so they're the boundary for who-can-touch-what. **Data Loss Prevention (DLP) policies** are the big one. A DLP policy sorts connectors into groups - typically "business" (work data) and "non-business" (everything else) - and **forbids a flow from mixing data across the groups**. The practical effect: an admin can stop anyone from building a flow that pulls data out of SharePoint and pushes it to a personal Dropbox or a public social account. The connectors won't combine in the same flow. It's the main lever stopping accidental data leaks. **The Power Platform admin center** is where this is run - admins manage environments, set DLP policies, see who's building what, and decide who's even allowed to create flows. They can also limit who gets premium and RPA licenses, which is its own form of control. Two failure modes to design against: - **Flows owned by people who left.** A flow runs as the person who built it. When they leave and the account is disabled, the flow dies - often silently. Use service accounts or shared ownership for anything important, so a flow doesn't depend on one human's login surviving. - **Sprawl with no inventory.** Hundreds of undocumented flows is a maintenance and security problem. Give things clear names, keep critical flows in a managed environment, and let admins see the landscape. That's the full shape of Power Automate: cloud flows that react to events across 365, connectors and approvals that turn events into real workflows, and desktop RPA for the stubborn old apps - all sitting inside governance that decides what's safe, what's allowed, and what it costs. Build with the license check up front and the maintenance owner named, and it'll serve you for years. Skip those, and you'll spend more time fixing automations than the manual work ever took.