Power Automate vs a custom build: when Microsoft's tools are enough

The flow nobody owns

Someone in operations built a flow two years ago. When a form is submitted, it creates a SharePoint item, emails the manager and posts in a Teams channel. It works. Everyone relies on it.

Then that person moves to another role. The flow runs under their account. A password policy changes, a connection expires, and the flow stops. Nobody notices for a week, until a customer asks why nobody replied.

That story isn't a knock on Power Automate. It's the most common way any automation tool fails. It's also the right place to start thinking about Microsoft's tools: what they're great at, and what they need around them to stay reliable.

What Microsoft gives you

The Power Platform is a family of tools. Two matter most here.

• Power Automate runs workflows. Cloud flows connect to software through connectors and run on a trigger or a schedule. Desktop flows automate clicks and typing on a Windows machine, for software with no other way in.
• Power Apps builds simple apps: forms, approval screens and small internal tools, often on top of SharePoint lists or Dataverse, Microsoft's own database.

Both are genuinely good. Microsoft offers a large catalog of connectors, built-in approvals, and tight links to Outlook, Teams, SharePoint and Excel. For a team already living in Microsoft 365, the distance from idea to working flow is short.

Licensing, without the prices

Licensing is where most surprises come from. Prices change, so we won't quote them. The structure is what matters for planning, and Microsoft's documentation lays it out.

Included with Microsoft 365. Many Microsoft 365 licenses include the right to build and run cloud flows with standard connectors. Microsoft lists SharePoint, Outlook and Teams among those. These seeded rights have lower daily action limits than the premium licenses.

Premium connectors. Many connections to systems outside Microsoft 365 are classed as premium. Microsoft's own licensing FAQ names SQL Server as an example. Using a premium connector generally requires a Power Automate Premium license for the user, or a Process license assigned to the flow.

Process licenses. These are assigned to a flow or a machine rather than a person. On a flow, they unlock premium connectors no matter who triggers it, and raise its daily action allowance. On a machine, a Process license becomes an unattended bot that runs one desktop flow at a time.

Power Apps. People who use an app with premium features, like premium connectors or Dataverse, need a license that covers premium use. Microsoft says it will enforce this more strictly from February 2027 for some scenarios, including apps in managed environments and model-driven apps. If you have apps that have been running leniently, review licenses before then. Microsoft also stopped selling the Power Apps per app license to new customers through some channels from January 2026.

Pay-as-you-go. An environment can be linked to an Azure subscription and billed by usage instead of buying licenses up front.

The practical takeaway: a flow that only touches Microsoft 365 is often covered already. The moment it reaches a database, your ERP, or a CRM outside Microsoft, ask what license it needs. Microsoft's licensing guide is the final word. Your Microsoft partner or account team can confirm your case.

Desktop flows: Microsoft's version of RPA

Power Automate also includes desktop flows. These drive Windows applications the way a person would, by clicking and typing. Microsoft positions them for software that has no connector and no other route in.

Desktop flows come in two modes. Attended runs happen on a person's machine while they're signed in, often triggered by them. Unattended runs happen on a machine with nobody watching, usually overnight or on a schedule.

The licensing follows that split. Power Automate Premium covers attended runs on the user's own registered machine. Unattended runs need a Process license allocated to the machine, and each one runs a single desktop flow at a time. Microsoft also offers hosted machines it runs for you, under a separate Hosted Process license.

Desktop flows share the weakness of every screen-based bot: when the screen changes, they can break. Our guide to RPA vs AI automation covers when that trade-off is worth it.

Governance: the part that decides success

Power Automate makes it easy for anyone to build. That's the point, and also the risk.

Microsoft gives admins real controls. Data policies sort connectors into groups and stop a single flow from mixing, say, your business data with a personal storage service. Environments separate testing from production. Managed environments add more oversight. The Center of Excellence starter kit helps admins see what exists across the company.

Those controls only help if someone uses them. Before you scale up, settle a few things:

• Who owns each important flow, and who is the backup.
• Which flows run under a shared service account rather than one person's login.
• Where flows are tested before they touch live data.
• Who gets told when a flow fails, and how fast.

Microsoft's own documentation notes that a cloud flow that fails continuously for 14 days gets turned off. Some flows without trigger activity for 90 days can also be suspended. Neither is a problem if someone is watching. Both are a problem if nobody is.

Where it strains at scale

Power Automate handles a lot. It has limits, and Microsoft documents them clearly.

• Daily action allowances. Each license carries a number of actions per day. A flow that loops over thousands of records can use them up quickly, and flows that run consistently over their limits slow down.
• Run length. A single run can last up to 30 days, including time waiting for approvals. After that, pending steps time out.
• Loops and lists. There are caps on how many items a loop can process and how many run in parallel. Large data jobs need careful design.
• Complex logic. Flows get hard to read past a certain size. Nested conditions and error handling spread across dozens of steps are hard to test and harder to hand over.

None of this is a reason to avoid Power Automate. It's a reason to know which processes belong there and which belong somewhere else.

AI inside the Power Platform

Microsoft includes AI Builder credits with Power Automate Premium and Process licenses. AI Builder offers prebuilt models for jobs like reading invoices and receipts, and the credits cover a set amount of use each month. For modest volumes inside Microsoft 365, that's a reasonable place to start.

Watch the credits as volume grows, and test reading quality on your own documents the same way you would any other tool.

When Microsoft's tools are enough

Power Automate and Power Apps are usually the right call when:

• The process lives mostly inside Microsoft 365.
• Volume is modest and the logic fits on one screen.
• The users are your own staff, already licensed.
• Someone on your team can own and maintain it.

Approval routing, notifications, moving files between SharePoint and Teams, simple forms: these are home ground. Don't replace a working flow just because it's low-code. Our guide on low-code vs custom development covers the broader trade-off.

When a custom build fits better

• High volume, where per-action allowances and loop limits start shaping the design.
• Logic complex enough that it needs proper testing and version history.
• Customers, partners or suppliers who need to use it, and aren't on your Microsoft licenses.
• A core system with no good connector, where the alternative is a desktop bot clicking through screens.
• AI steps that need careful review, logging and control over which model sees what.

A custom build doesn't mean leaving Microsoft. It can sit in your Azure account, sign in with your Microsoft accounts and post to the same Teams channels. Our Microsoft 365 integrations page covers what we connect to.

Questions for your Microsoft admin

Before you commit a process to the Power Platform, get answers to these from whoever runs your Microsoft tenant:

1. Which licenses do our users have today, and do they include premium connectors?
2. What data policies are in place, and would this flow's connectors be allowed together?
3. Is there a separate environment for testing, or does everything run in the default one?
4. Do we have service accounts for important flows, or does everything run as individual people?
5. Who monitors failed flows today, and how would they hear about this one?

If the answers are mostly "we don't know," that's useful too. It means the first project is partly about setting up the ground rules.

What most guides miss

Mixed is normal. The best setups often keep Power Automate for team-level flows and move only the heavy or critical process to custom code. You don't have to pick one for the whole company.

Count the licenses per person, not per flow. A Power App that works for five people in a pilot may need premium licensing for five hundred at rollout. Do that math before the pilot, not after.

Service accounts save weekends. Flows tied to one employee's login break when that person leaves. Running important flows under a dedicated account, with documented owners, prevents the most common outage.

How we do it

We start with a free intro call and a look at what you've already built. We work alongside your Microsoft admin, keep what works, and build custom only where the platform strains. We stay on after launch. Start with an intro call.

Sources

1. Microsoft Learn: Types of Power Automate licenses
2. Microsoft Learn: Deep dive on specific Power Automate licenses (seeded licenses)
3. Microsoft Learn: Power Apps licensing FAQs
4. Microsoft Learn: Licensing overview for Microsoft Power Platform
5. Microsoft Learn: Limits of automated, scheduled and instant flows
6. Microsoft Learn: Data policies
7. Microsoft Learn: Center of Excellence starter kit