Workflow automation platforms: who runs it after you buy.

Which of the workflow automation platforms should we buy? Every page that ranks for the phrase answers with a ranked list, usually thirteen products long, with the author's own product in first place and a feature table underneath. This article refuses to answer that way, because the list answers the wrong question.

The better question comes from a cost study Forrester Consulting ran for Microsoft in July 2024 on Power Automate, one of the largest platforms in the category. Over three years, the composite customer paid $1.0 million to implement the platform and $3.3 million for the team of five developers who managed it afterwards. The build was a one-off. The running cost was more than three times larger, and it recurred.

That ratio, roughly one part build to three parts running, is the number to carry into any comparison of workflow automation platforms. The feature grids are mostly tied. The platforms differ in who does the running, what unit you pay by, and how often the thing breaks. Those three differences are what this article compares.

What is a workflow automation platform?

A workflow automation platform is software that moves data and decisions between your other applications on a trigger or a schedule, so a routine runs without a person carrying it from one screen to the next. A new order in the web shop creates an invoice in the accounting system and a line in the warehouse sheet. A support email is classified and routed. The platform supplies the connectors, the logic editor, the run log and the retry rules.

The phrase covers four families that get listed together but behave differently. Integration platforms such as Zapier, Make and n8n connect cloud apps through a visual editor and price by task or execution. Enterprise process platforms such as Microsoft Power Automate, Workato and Camunda add governance, on-premises connectors and per-user or per-flow licensing. Robotic process automation tools such as UiPath drive the screens of older systems that have no API. The newest family wraps a language model around the same connectors and calls the result an agent platform.

A fifth option rarely appears on the lists, because it is a service rather than a product: someone builds the routine on their own platform and runs it for you, and what you buy is the working automation. It belongs in the comparison because, for a buyer, it answers the same question the platforms do. The difference is in who holds the editor.

The platforms differ on four axes, and features are not one of them.

Feature tables in the published comparisons converge within a year, because every platform copies the connector or trigger its rival shipped. The durable differences are four:

• Who is expected to build and repair each routine
• What unit the bill counts
• Where the platform runs
• Where the AI step sits in the flow

A buyer who sorts the market by those four will reach a shortlist faster than one who counts connectors.

Who builds is the first axis. Zapier, Make and the no-code family assume a person in the business draws each routine. n8n and Power Automate assume that person is comfortable with expressions and, on the harder flows, code. Workato and Camunda assume a developer. Every one of them assumes the same person, or a replacement with the same skill, is still there to repair the routine after it breaks. A separate piece covers what to check before buying a no-code platform and reaches the same conclusion from the other side.

The billing unit is the second. Per task or per execution, the Zapier and Make model, is cheap for ten routines and expensive for one routine that fires every minute. Per user, which is Power Automate's standard licence, is cheap for a small team and punishes the organization that wants everyone using it. Per flow or per connection, the Workato model, rewards consolidation. A flat price for a package of working automations is the unit a managed service sells. None of these is wrong. Each one decides which of your routines you will quietly decline to automate because the meter would run.

Hosting is the third axis, and it splits the market cleanly. Cloud-only platforms carry the security patching for you. Self-hosted options such as n8n hand it back. That is why n8n's own community forum carries a long thread on the honest cost of a year of self-hosting. The fourth axis, where the AI step sits, is newer. On most platforms the model is one node in the chain, and it is the only node whose output is a probability rather than a lookup. Where that node sits decides how often the whole run is right, which a later section covers.

What does a workflow automation platform cost after the licence?

The licence is the visible cost and, in the one primary cost study in the category, the largest. The Forrester Consulting Total Economic Impact study of Microsoft Power Automate was published in July 2024 and commissioned by Microsoft. It built a composite 30,000-employee organization from six interviewed customers. Over three years it paid $11.8 million in licensing, $1.0 million for implementation and training, and $3.3 million for ongoing management, for a total of $16.1 million.

Read the three figures with care, because they fight each other if you let them. The licence was 73% of the total, so on this evidence the platform is the larger half of the bill, and anyone who tells you the licence is a rounding error is overselling. The ratio that matters is the second one: the five developers "dedicated to managing the solution on an ongoing basis" cost 3.3 times what the implementation did, and that cost does not stop in year four. The study was commissioned by the vendor, which makes the management figure more credible. A sponsor has no reason to inflate the cost of keeping its own product running.

Scale the composite down to a 200-person company and the licence shrinks with the headcount, while the management cost shrinks much more slowly. Someone still has to own the run log, the credentials and the fix when a connector stops. At that size the owner is usually not a dedicated developer. It is an operations manager who built the first routine in an afternoon and now spends part of every week on the twenty that followed. Our piece on why enterprise automation programs stop at ten processes traces what happens when that person's week runs out.

Why do automations on any platform keep needing repair?

Automations break because the applications on either end of them change, and the count of those applications keeps rising. Camunda's State of Process Orchestration and Automation 2025, a January 2025 survey of 800 IT and business leaders, found that organizations now manage an average of 50 endpoints to execute the tasks in a single process, up 19% in five years. In the same survey, 79% said they had implemented significant automation while lacking an effective way to control and sustain it, and 77% reported core process failures.

Each endpoint changes on its own schedule, and the change often arrives unannounced. Postman's 2025 State of the API report, drawn from more than 5,700 respondents, found that 60% of teams version their APIs at all and only 26% use semantic versioning, the convention that tells a caller whether an update will break it. Seventeen percent run no monitoring. The practical reading for a buyer: most of the fifty endpoints your routine touches will change something about their interface without telling your platform what the change means.

This is also where the AI axis from earlier matters. If a routine has ten steps and each one is right 95% of the time, only 59.9% of complete runs come out right, because 0.95 to the tenth power is 0.599. A platform that puts a language model at several points in the chain multiplies probabilities. One that keeps the connecting steps as tested code and uses the model only where the input is unstructured keeps the arithmetic on the buyer's side. That is why Uplift builds with 95% tested code and 5% AI, as described on how we build. Whichever platform you shortlist, ask where the probabilistic steps sit and how many there are.

Per task, per seat or flat: which pricing should you choose?

Choose the unit that will not make you ration automation. Per-task pricing is the right choice for a company with a handful of low-volume routines, because the bill stays close to zero until the routines earn their keep. Per-seat pricing suits a small, stable team that will build and use the automations itself. A flat price for a package of working automations suits the company that wants every department to have them and nobody counting.

The failure mode of each unit is predictable. Per-task meters make teams avoid the high-frequency routines that would save the most hours, because a flow that runs every minute costs real money. Per-seat licences make the automation a privilege of the people with a seat, so the warehouse and the field staff do without. Both are forms of the same tax: the price rises in proportion to how much the automation is used, which is the opposite of what you want from a thing whose whole point is to be used.

Uplift's answer is deliberate. There are no tokens, no meters and no per-seat licences, and no surprise bill at the end of the month. A customer buys a package of working, tested, maintained automations at a flat price, and everyone in the organization can use them. The honest counterpart: a flat price is more than a per-task bill for the company with three small routines, and that company should buy the per-task tool. The flat model earns its price at the point where the meter would otherwise have started deciding what gets automated.

Who should run it: your team, an outside builder, or a managed service?

Whoever runs it needs the hours every week, for as long as the routine lives, and the comparison between those three choices matters more than the comparison between platforms. Forrester's finding that fewer than 15% of employees given low-code tools go on to use them is the number that decides this. Buy a platform for the whole company and one employee in seven picks it up. It is the fishing-rod problem: everyone gets a rod, and six of the seven go into a closet.

Hiring an outside builder, an agency or a development shop, solves the skill problem for the length of the engagement. They fish well while they are here. When the contract ends, the knowledge of the water goes home with them, and you own a set of flows on your account that nobody on staff built. For some buyers that is exactly right: they want the asset, they have an IT team to inherit it, and a codebase or a workspace of flows at the end is worth the handover risk. If that describes you, a development shop is the better purchase than a managed service, and you should say so to any supplier offering something else.

The managed route is what Uplift sells. You describe the routine in plain language. We build it, mostly from tested code with a small AI step, then run it, watch the log and repair it when one of the fifty endpoints changes. When a company does not know which routines to start with, the Brainstormer reads each role and proposes the routines worth handing over. It learned what pays back from over 14,000 real automations built by people in roles like yours. The cost of this model, stated in the same register as everything above: you do not end up holding a codebase, and the automations stop when the plan does. We have no written exit clause to quote. So ask any supplier making a similar offer, Uplift included, what you hold on the day the plan ends, and read a vague answer as a no. The page for your team describes how the arrangement looks from inside a company that chose it. Our piece on low-code workflow automation covers the middle path, where a team keeps the editor and buys help with the upkeep.

When a workflow automation platform is the wrong purchase.

Some routines should not be automated on any platform, and no comparison table will tell you which. A process that is broken, with three people doing it three ways, gets faster at producing the wrong result. A routine that runs four times a year never repays the build. A routine whose rules live in one person's head will spend the build phase extracting them and the first year discovering exceptions. The person in question is usually the one who would have had to own the automation.

The cheapest test is to write the routine down as instructions a new hire could follow. If that takes under a page and the new hire could do it on their first day, it is a candidate for any of the platforms above, and the choice between them comes down to the four axes and the billing unit. If the page runs to five, or the instructions keep saying "it depends", you have found a process problem. Buying software for it is the expensive way to learn that. Fix the process first. The platform question will still be there afterwards, and it will be easier to answer.