Power Automate makes a promise that is easy to believe and expensive to test: that the automation your team has been asking for is a Tuesday afternoon of clicking, not a project. Sometimes that is exactly true. Sometimes the same flow becomes the thing nobody can change, nobody can debug and nobody can licence affordably eighteen months later.
The question is not whether Microsoft Power Automate is good. It is genuinely good at what it is for. The question is whether the specific process in front of you belongs on a hosted low-code platform or in code you own, and that answer changes with volume, with how often the logic moves, with who is expected to maintain it, and with what happens when a step fails halfway through a transaction.
This guide is the working comparison. It covers what each option actually is, where each one wins outright, how the licensing model behaves once you are past the pilot, what five years costs on both paths, the governance and throughput ceilings that decide most real cases, and the hybrid pattern that mature teams settle on. It draws on our workflow automation and business process automation practice, and it is written for the person who has to defend the choice in a budget meeting.
If you are still one level up — deciding between orchestration, screen-driving robots and agents rather than between two build routes — start with our comparison of workflow automation, RPA and AI agents and come back here once the category is settled.
Table of contents
- What Power Automate is, and what custom workflow development actually means
- Where Power Automate wins outright
- Where custom workflow development wins outright
- The Power Automate licensing model is where budgets go wrong
- Five-year cost: Power Automate versus a custom build
- Power Automate governance, ALM and the sprawl problem
- Throughput, limits and the Power Automate performance ceiling
- Integration reach: connectors versus code
- Maintenance, support and who owns the thing at 2am
- Power Automate security, compliance and data residency
- The hybrid pattern most mature teams end up with
- A five-question test for choosing between Power Automate and a custom build
- A 90-day plan to de-risk the decision
- Frequently asked questions about Power Automate and custom development
- References
What Power Automate is, and what custom workflow development actually means
The two options get compared as if they were two products on a shelf. They are not. One is a platform you rent with a runtime, a designer and a connector catalogue included; the other is a set of engineering decisions you make and then own. Naming that difference precisely is most of the work.
Power Automate is a hosted orchestration platform with a connector catalogue
Power Automate holds the flow definition, runs it on Microsoft’s infrastructure, and reaches other systems through a large library of pre-built connectors. You describe the trigger, the conditions and the actions in a designer; Microsoft handles the servers, the scaling, the retries and the upgrade path. Cloud flows cover API-to-API work, and desktop flows cover the systems that expose no API at all.
Custom workflow development is code you own end to end
A custom build is an application: a durable orchestrator such as Temporal or Camunda, or a queue plus workers plus a state store, written in a language your team already uses, deployed on infrastructure you already run. Nothing about it is inherently more sophisticated than a flow. What it gives you is total control of behaviour, cost and failure semantics, and total responsibility for all three.
The dividing line is who owns the runtime
Every practical difference below follows from that one line. On Power Automate, Microsoft owns the runtime and you accept its limits, its pricing meter and its release cadence in exchange for never operating it. On a custom build, you own the runtime and you get to set the limits, the cost curve and the failure behaviour — and you pay for the privilege in engineering time, on day one and every year after.
Neither one is the “serious” option
The instinct that low-code is for simple things and code is for real systems is wrong often enough to be dangerous. Plenty of business-critical processes run happily on Power Automate for years. Plenty of trivial-looking custom services exist because one integration had a three-second latency budget. Judge the process, not the tool’s reputation.
| Factor | Power Automate | Custom workflow development |
|---|---|---|
| Time to first working version | Hours to days | Weeks |
| Who can build it | Business users with support | Software engineers |
| Upfront cost | Near zero | Substantial |
| Cost at scale | Rises with users, flows and requests | Flat once built |
| Throughput ceiling | Set by licence and platform limits | Set by your infrastructure |
| Failure handling | Built-in retry, limited compensation | Whatever you design |
| Testing and version control | Solutions and pipelines, improving | Standard engineering practice |
| Vendor dependency | High | Low |
| Best fit | Microsoft 365 processes, approvals, moderate volume | Core operations, high volume, distinctive logic |
Where Power Automate wins outright
There is a class of process where reaching for a custom build is simply the wrong instinct, and an experienced team recognises it in about five minutes. These are the cases where Power Automate is not the compromise — it is the correct engineering answer.
Processes that live inside Microsoft 365
If the data starts in SharePoint, moves through Outlook and Teams, and ends in Excel or Dataverse, Power Automate is already inside the tenant with authentication, permissions and audit handled. Rebuilding that plumbing in code means reimplementing Microsoft Graph access, token refresh and permission scoping for no gain. The connector catalogue exists precisely so you never write that code twice.
Approvals, notifications and low-volume routing
Approval chains are the canonical Power Automate use case for a reason. The built-in approvals engine, the mobile notifications and the Teams adaptive cards would take weeks to reproduce and would never be as polished. For a process running a few hundred times a month, the platform’s overhead is invisible and its convenience is enormous.
Automations a business team should own
When the rule is “if the invoice is over £5,000 route it to the finance director”, the person who knows that rule should be able to change it. Power Automate lets the finance team edit that threshold without a ticket, a sprint and a release. That is a genuine organisational win, and it is the single strongest argument for the platform.
Anything you need working this week
Speed of first delivery is not a soft benefit. A process that is automated badly this month usually beats one that is automated beautifully next year, because the manual cost is running the whole time. Power Automate is unmatched at getting something real in front of users fast, and a flow is cheap to throw away if the process turns out to be wrong.
Prototyping the process before you commit
Even when the end state is obviously a custom build, a flow is often the cheapest way to discover what the process actually is. Teams routinely find that the documented process and the real one differ, and it is far better to learn that from a two-day Power Automate prototype than from a two-month sprint.
Where custom workflow development wins outright
The opposite class is equally clear once you know what to look for. These are the signals that a flow will fight you, and that the fight gets worse rather than better as the process matures.
Long-running, stateful processes with real orchestration needs
A process that runs for days, waits on external events, needs compensation when step seven fails after step three already moved money, and must be resumable after an outage is a distributed systems problem. Durable execution engines such as Temporal and Camunda exist for exactly this. Power Automate can approximate it; it was not designed for it.
High volume and tight latency budgets
Once a process runs tens of thousands of times a day, or has to answer in under a second, the platform’s per-request accounting and cold-start behaviour become the constraint. Code running next to your data on infrastructure you tune does not have that ceiling. This is the most common reason a successful flow eventually gets rewritten.
Logic that is your competitive advantage
Pricing engines, matching algorithms, underwriting rules, allocation logic — the things competitors cannot copy — belong in a codebase with tests, review and version history. Expressing genuinely intricate rules in a visual designer produces something correct but unreadable, and unreadable business-critical logic is a liability, not an asset.
Systems with no usable connector
Some line-of-business systems expose a proprietary protocol, a database only, or an API that behaves badly under the assumptions a connector makes. You can write a custom connector, but at that point you are already writing code — and writing it inside someone else’s execution model rather than your own.
When the maintenance budget is real and the licence budget is not
This one is organisational rather than technical. Some businesses can fund a permanent engineering capability but cannot get a growing per-user subscription past procurement. Others are the exact opposite. Both constraints are legitimate inputs, and pretending the decision is purely technical is how business cases fall apart in review.
The Power Automate licensing model is where budgets go wrong
Almost every unpleasant surprise in a Power Automate programme is a licensing surprise, not a technical one. The pilot runs on rights already included in Microsoft 365, everything works, and then the first serious flow touches a premium connector and the pricing conversation starts from scratch.
Seeded licences are not a free tier
Microsoft 365 subscriptions include Power Automate use rights, but they are scoped: standard connectors only, within the context of the apps you already pay for, with a modest daily request allowance. That is enough for a pilot and genuinely useful for simple work. It is not a foundation for an automation programme, and treating it as one is the most common planning error.
Premium connectors move the price
The moment a flow touches SQL Server, Salesforce, an HTTP action, a custom connector or Dataverse in earnest, you are in premium territory and every user who triggers that flow needs a licence. Check the current numbers on the Power Automate pricing page rather than a figure someone remembers, because this is the line item that moves.
Per-flow licensing changes the arithmetic
For unattended processes that serve a whole department, a per-process licence attached to the flow rather than the people is usually far cheaper than licensing every user who touches it. The arithmetic flips somewhere around the point where the flow serves more than a handful of named users, and knowing which side of that line you are on is worth an hour of modelling.
The request limit is the real meter
Power Automate bills capability by licence and consumption by request. Every action in every run counts against a daily allowance documented in Microsoft’s request limits and allocations guidance. A loop that seemed harmless in testing can burn a day’s allowance in an afternoon at production volume, and the failure mode is throttling, not a bill — which is worse when the process is time-sensitive.
| Licence route | What it unlocks | Meter | Typical fit |
|---|---|---|---|
| Seeded with Microsoft 365 | Standard connectors, in-app context | Per user, low daily allowance | Pilots, personal productivity |
| Premium, per user | All connectors, custom connectors, Dataverse | Per user, higher allowance | Teams building many attended flows |
| Process, per flow | Unattended runs, whole-department reach | Per flow, high allowance | Shared back-office automation |
| Hosted process | Microsoft-hosted desktop-flow machines | Per flow, includes compute | RPA without managing VMs |
| Custom build | Everything you write | Infrastructure only | High volume, distinctive logic |
Five-year cost: Power Automate versus a custom build
A one-year comparison always flatters the platform and a ten-year one always flatters the custom build, so five years is the honest window. The figures below are indicative for a mid-sized UK organisation automating one substantial back-office process; treat the shape as the point, not the pounds.
What a realistic comparison includes
Four cost lines matter and most business cases include two. Build cost is obvious. Licence or infrastructure cost is usually estimated. Run cost — monitoring, incident response, the person who checks the failure queue — is routinely forgotten. Change cost, the price of every modification over five years, is the one that actually decides the answer, and it is almost never modelled.
The crossover point
On Power Automate you start cheap and pay a rising subscription; on a custom build you pay a large upfront and then very little. Those lines cross somewhere between year two and year four for most processes, earlier if user count or volume grows, later if the process is small and stable. Our cost optimization work is mostly about finding that crossover before it finds you.
The cost that never appears in the business case
Neither column below includes the cost of getting it wrong: the rebuild when a flow hits a ceiling, or the maintenance drag of a custom service nobody wanted. That risk cost is real, and it is the strongest argument for prototyping on Power Automate before committing to code — the prototype is cheap insurance against building the wrong thing beautifully.
| Cost line (5 years, indicative) | Power Automate | Custom build |
|---|---|---|
| Initial build | £8,000 – £25,000 | £45,000 – £120,000 |
| Licences or hosting | £60,000 – £150,000 | £6,000 – £20,000 |
| Run and support | £15,000 – £30,000 | £30,000 – £70,000 |
| Change and enhancement | £10,000 – £25,000 | £40,000 – £90,000 |
| Indicative five-year total | £93,000 – £230,000 | £121,000 – £300,000 |
| Sensitivity | Scales with users and volume | Scales with change frequency |
A useful way to read that table is by where each pound goes rather than by the totals, because the mix is what changes when your assumptions change.
Power Automate governance, ALM and the sprawl problem
The technical comparison is only half the decision. The other half is what happens when the platform succeeds and there are four hundred flows instead of four, built by people who have since changed jobs. Every organisation that adopts Power Automate seriously meets this problem, and the ones that planned for it barely notice.
Environments are the unit of control
Development, test and production separation is not optional once a flow matters. Microsoft’s environments model gives you that boundary, and using a single default environment for everything is the decision most teams regret. Set the environment strategy before the second serious flow, not after the first incident.
Solutions, pipelines and source control
Managed solutions and deployment pipelines bring Power Automate much closer to normal engineering practice than its reputation suggests, and the application lifecycle management guidance is worth reading before you build rather than after. It is still not equivalent to a Git history with meaningful diffs, which remains a genuine advantage of a custom build.
The orphaned-flow problem
A flow built by someone who has left the business, running under their personal connection, silently doing something important, is the characteristic Power Automate failure. Connections are owned by individuals unless deliberately made otherwise, and offboarding breaks them. Custom services do not have this failure mode; they have their own, but not this one.
A Centre of Excellence is not optional at scale
Past roughly fifty flows, informal governance stops working. Microsoft’s Centre of Excellence starter kit gives you inventory, orphan detection and usage telemetry, and the adoption methodology covers the organisational side. This is IT governance work, and budgeting for it is part of the honest cost of the platform.
Throughput, limits and the Power Automate performance ceiling
Every hosted platform has limits, and the ones that matter are rarely the ones in the marketing material. On Power Automate the constraints that bite in production are request allowances, concurrency caps and the latency floor imposed by running someone else’s runtime.
Request allowances are per licence, per day
The daily Power Platform request allowance is attached to the licence, and every action in a flow run consumes from it. A flow that iterates over a thousand rows and takes three actions per row is not one request, it is three thousand. Model this before you build, using the published limits and configuration figures, because discovering it in production means throttling during your busiest hour.
Concurrency and loop limits
Apply-to-each loops have a concurrency ceiling, nested loops have depth limits, and pagination has row caps. None of these are unreasonable for the platform’s intended use, and all of them are the sort of thing a custom build simply does not have. When a process is fundamentally a batch job over a large dataset, the mismatch is structural rather than a tuning problem.
Latency is not the platform’s strength
Flows are optimised for throughput of business events, not for sub-second response. If a customer is waiting on the result, or an upstream system times out at two seconds, Power Automate is the wrong layer and something like an Azure Function or a service in your own stack belongs there instead.
Check the current allocation figures before you rely on that shape — Microsoft revises them, and the ratio matters more than any single number.
Integration reach: connectors versus code
Integration breadth is the argument most often used for the platform, and it is a strong one. It is also the argument most often overstated, because “there is a connector” and “the connector does what you need” are different claims.
The connector catalogue is genuinely large
Over a thousand connectors covering Microsoft, Salesforce, SAP, ServiceNow, Google, AWS and a long tail of SaaS products is a real asset, and the connector reference is the first place to look when scoping. Reproducing even five of those integrations properly — auth, refresh, pagination, rate limits, error semantics — is weeks of work you do not have to do.
Custom connectors close some of the gap
When a system has a REST API but no connector, a custom connector wraps it and makes it available to every flow in the environment. This is genuinely powerful and under-used. It also means you are now maintaining an integration definition, which is a small custom build living inside the platform.
Where code still wins
Connectors abstract, and abstractions leak. When you need a specific header, an unusual auth flow, streaming, bulk operations, or precise control of retry and idempotency, the connector’s shape becomes the problem. A well-designed integration layer in your own stack — the kind our DevOps and platform work usually ends up building — has none of those constraints and all of the maintenance burden.
Maintenance, support and who owns the thing at 2am
Both options need an owner. The difference is what that owner does, which skills they need, and how visible the work is to the people funding it.
Power Automate shifts maintenance, it does not remove it
Microsoft patches the runtime, so you never do. You still own flow logic that breaks when an upstream form changes, connections that expire, licences that lapse and errors that queue up silently. The work is smaller and less technical than maintaining a service, and it is consistently underestimated to zero in business cases.
Custom builds need a named owner and a runbook
A custom workflow service needs dependency updates, security patching, capacity headroom and someone who can be called when it stops. If that capability does not exist internally, it has to be bought — through managed IT services or a retained development partner — and that cost belongs in the comparison from the start, not as a surprise in year two.
Observability is the honest differentiator
Power Automate gives you run history: what ran, what failed, what the inputs were. It is good, and for most flows it is enough. A custom build gives you whatever you instrument — structured logs, traces, metrics, alerting tied to business outcomes rather than technical failures. On a process where a silent partial failure costs real money, that gap is the strongest technical argument for owning the code.
Handover risk cuts both ways
A flow nobody documented is as opaque as a service nobody documented. The platform makes the logic visible in a designer, which helps; it also makes it easy to build something intricate without ever writing down why. Insist on the same documentation standard either way.
Power Automate security, compliance and data residency
For regulated work the security question usually decides the architecture before cost is discussed at all, and it is worth resolving early rather than treating it as a compliance sign-off at the end.
DLP policies are the main control surface
Data loss prevention policies classify connectors into business and non-business groups and block flows that would bridge them. Microsoft’s data loss prevention guidance is the reference, and configuring it properly is the single highest-value governance action available on the platform. Without it, a well-meaning user can move regulated data into a personal service in four clicks.
Connection ownership is a real risk
Flows run under a connection, and that connection carries someone’s permissions. A flow built by an administrator inherits administrative reach, which is fine until the flow is edited by someone else. Service principals and dedicated service accounts fix this, and they are not the default — which is exactly why this belongs on the pre-build checklist rather than the post-incident one.
Data residency and regulated workloads
Power Automate runs where the tenant’s environment runs, and that is configurable but not unlimited. If a contract requires processing in a specific jurisdiction, on specific infrastructure, or inside a private network with no public egress, verify it explicitly. A custom build can be placed anywhere you can run software, which is occasionally the only thing that matters.
The general principle still applies
Whichever route you take, the automation inherits the security posture of the systems it touches and the credentials it holds. The OWASP Top Ten risks do not stop applying because the logic is drawn rather than typed, and an automation with broad permissions is a high-value target either way.
The hybrid pattern most mature teams end up with
After a few years of running both, most organisations stop asking which one to standardise on. The useful question becomes which layer each part of a process belongs to, and the answer tends to converge on the same shape.
Power Automate at the edges, code in the middle
The pattern is straightforward: use Power Automate for the human-facing edges — the form, the approval, the notification, the Teams message, the SharePoint filing — and a custom service for the part with volume, complex state or distinctive logic. The flow calls the service; the service does the work and returns a result the flow can act on.
A custom connector as the contract
Expose your service through a custom connector and it becomes a first-class action in the designer. Business users assemble processes around it without touching the code, and the engineering team changes the implementation without breaking their flows. That interface is what makes the hybrid maintainable rather than merely coexistent, and it is worth the extra day it costs to define properly.
One example end to end
A claims process illustrates it well. Power Automate catches the submission, files the documents, and routes the approval; a custom service runs the eligibility rules against ten years of history, calculates the settlement, and writes to the ledger transactionally. Neither layer is doing the other’s job, and each one can be changed by the people who should be changing it. This is the shape most of our intelligent automation engagements end up delivering.
A five-question test for choosing between Power Automate and a custom build
When a specific process is in front of you, five questions resolve most cases in under an hour. Answer them honestly, including the ones with uncomfortable organisational answers.
1. Does the process stay inside systems Power Automate already reaches?
If every system involved has a mature connector and the data volumes are moderate, the platform is very likely the right answer and the burden of proof sits with anyone arguing for code. If two of the systems need custom connectors, that advantage has already evaporated.
2. How often will the logic change, and who changes it?
Frequent changes made by business users point hard at Power Automate. Rare changes made by engineers point at a custom build. Frequent changes made by engineers is the genuinely awkward case, and it usually resolves toward code with a well-designed configuration layer.
3. What happens when a step fails halfway through?
If the answer is “retry it”, the platform is fine. If the answer involves compensating transactions, partial rollback, reconciliation or “it must never double-pay”, you need explicit control of failure semantics, and that means code. This question alone decides more cases than cost does.
4. What is the volume, and what is the latency budget?
Hundreds of runs a day with minutes of tolerance is comfortable platform territory. Tens of thousands of runs with a sub-second budget is not. Between those extremes, model the request consumption honestly rather than assuming the licence covers it.
5. Is this logic a differentiator or a commodity?
Commodity processes — onboarding paperwork, expense routing, document filing — should cost as little engineering attention as possible, and Power Automate is excellent at that. Logic that is the reason customers choose you belongs in a repository with tests, review and a history you can read.
| Process characteristic | Lean Power Automate | Lean custom build |
|---|---|---|
| Runs per day | Under ~2,000 | Over ~10,000 |
| Latency tolerance | Seconds to minutes | Sub-second |
| Failure semantics | Retry is sufficient | Compensation required |
| Who edits the rules | Business users | Engineers |
| Systems involved | Connectors exist and fit | Proprietary or awkward APIs |
| Logic complexity | Dozens of rules | Hundreds, or algorithmic |
| Strategic value | Commodity process | Competitive differentiator |
| Time pressure | Needed this quarter | Planned roadmap item |
A 90-day plan to de-risk the decision
Choosing on paper is guessing. Ninety days is enough to replace the guess with evidence, and it costs far less than the rebuild you avoid.
Days 1 to 30: map and measure
Document the process as it actually runs, not as the policy describes it. Count the real volume, the real exception rate, and the real cost of the manual version. Identify every system involved and check whether a connector exists and covers the operations you need. Most of the decision is made here, and most teams skip it.
Days 31 to 60: build the same process both ways
Build the happy path in Power Automate and a thin vertical slice in code. This is a fortnight of work, not a project, and it produces the two things a paper comparison cannot: a real estimate of build effort and a real measurement of platform limits against your actual data.
Days 61 to 90: decide with numbers
Model five years using the measured build effort, the licence count the prototype actually needs, and the request consumption you observed. Write the decision down with its assumptions, and set a review trigger — a volume threshold, a user count, a licence renewal — at which you revisit it. A decision with a documented trigger ages far better than one defended on instinct, which is the same discipline that makes digital transformation programmes survive contact with reality.
Keep the prototype either way
Whichever path wins, the Power Automate prototype earns its keep as documentation of what the process does. Keep it in a development environment, disabled, as the executable specification the custom build was written against.
Frequently asked questions about Power Automate and custom development
Is Power Automate suitable for business-critical processes?
Yes, with governance. Plenty of organisations run genuinely critical processes on it. What makes them safe is environment separation, solution-based deployment, service-account connections, monitoring of the failure queue and a named owner — not the platform itself. Without those, a critical flow is a critical risk regardless of how well it was built.
Can we start on Power Automate and move to custom code later?
Yes, and it is often the right sequence. The migration is real work — you are rewriting, not lifting — but the flow gives you a precise, tested specification of the process, which removes most of the discovery risk. Design for it by keeping business rules in a configuration layer rather than scattered through conditions.
What is the biggest hidden cost of Power Automate?
Licensing at scale, followed closely by governance. Both are invisible during a pilot and unavoidable in production. Model the licence count against the number of people who will trigger flows, not the number who will build them, and budget explicitly for the administration the platform needs once flow counts pass fifty.
Does Power Automate replace RPA?
It includes RPA — desktop flows are Microsoft’s robotic process automation offering, and they drive application interfaces the way a person would. The distinction that matters is API orchestration versus screen driving, and the two are licensed and operated differently even inside the same product. Our RPA page covers where screen automation still earns its place.
How does Power Automate compare with other automation platforms?
Its advantage is depth inside Microsoft 365 and the enterprise governance surface around it. Tools such as Zapier and Make are faster for lightweight SaaS-to-SaaS work, and we compare that trade-off directly in our Power Automate versus Zapier guide. Against a custom build the comparison is not features but ownership.
When is a custom build definitely the wrong answer?
When the process is not yet stable. Automating a process that will change substantially within six months is expensive on any platform and ruinous in code. Get the process right manually, prototype it on Power Automate, and only then consider whether it deserves a permanent engineering investment.
References
Microsoft Learn — Get started with Power Automate
Microsoft Learn — Overview of cloud flows
Microsoft Learn — Introduction to desktop flows
Microsoft Learn — Requests limits and allocations
Microsoft Learn — Limits and configuration
Microsoft — Power Automate pricing
Microsoft Learn — Power Platform licensing FAQ
Microsoft Learn — Solution concepts in ALM
Microsoft Learn — Environments overview
Microsoft Learn — Data loss prevention policies
Microsoft Learn — Centre of Excellence starter kit
Microsoft Learn — Power Platform adoption methodology
Microsoft Learn — Power Platform Well-Architected
Microsoft Learn — Connector reference
Microsoft Learn — Custom connectors overview
Microsoft Learn — Azure Logic Apps overview
Microsoft Learn — Azure Functions overview
Temporal — Understanding durable execution
Camunda — Process orchestration
Martin Fowler — Microservices
