Every enterprise operator eventually gets handed the same problem. A process that runs on email, spreadsheets, and someone's memory needs to become something the auditors and the board can trust. The word for the fix is workflow automation, and the moment you start shopping for it, you discover that at least four very different kinds of software all claim the label. This guide is written for the person who has to sign the contract and then run the thing for the next five years.
Introduction: what a buyer actually experiences
Workflow automation, in the analyst's telling, is a tidy category with a growth curve and a set of leaders. In the buyer's experience it is nothing of the sort. You start with a specific pain: approvals that stall, handoffs that get lost, a compliance step that only happens when the right person remembers it. You want that pain gone. What you meet instead is a market where a maintenance platform, a low-code suite, a heavyweight process engine, and a document management add-on will all sit across the table and tell you they solve it.
They are not lying, exactly. Each of them can automate a workflow. The difference is what you own afterward, how fast you get there, how far it stretches before it breaks, and what it costs you to leave. Those four questions, not the feature grids, are what separate a good decision from an expensive one. I have implemented automation inside ERP and CMMS platforms, wired low-code tools into enterprise systems, and cleaned up after full process engines that outgrew the team meant to run them. This guide segments the market the way it feels from the buyer's chair.
How the market actually breaks down
Forget the vendor logos for a moment. From where a buyer sits, workflow automation arrives in four shapes, and the shape matters more than the brand. Each shape has a natural home, a natural ceiling, and a very different bill when you want out.
a) Platform-native workflow
This is the automation engine already sitting inside the ERP, CMMS, or CAFM you paid for. Purchase approvals in your finance system, work order routing in your maintenance platform, status transitions in your service desk. You did not buy it as a product; it came in the box. Its great virtue is that the data never leaves home, so there is one system of record and one place to look.
b) General-purpose low-code suites
The horizontal tools, such as Microsoft Power Automate, that promise anyone can build a flow. Drag a trigger, drop an action, connect a few systems. They shine at the workflows that cross applications, the ones no single platform owns. They are fast to start and genuinely productive, right up until the logic gets complicated or the run counts get large, at which point the friendly pricing and the friendly interface both start to strain.
c) Dedicated BPM engines
Business process management platforms built to model (usually in a standard notation such as BPMN), execute, and govern serious processes. Long-running instances, complex branching, formal versioning, real governance. This is where you go when the process is the product, when it runs for weeks, spans departments, and has to survive an audit. The power is real and so is the weight; these tools assume you have people whose job is to run them.
d) Point tools bundled with a document or ITSM product
The workflow feature that ships alongside a document management system, an e-signature product, or an IT service desk. It exists to move that product's own artifacts along: route a contract for signature, escalate a ticket, push a document through review. Excellent inside its lane, awkward the moment you ask it to reach beyond the host product it was built to serve.
| Segment | Typical cost | Time to first value | Ceiling of complexity | Exit cost |
|---|---|---|---|---|
| Platform-native | Bundled, often near zero incremental | Days if the process fits the platform | Moderate; bounded by the host app's model | Low; the flow lives with data you keep |
| Low-code suite | Low to enter, scales with users and runs | Days to a couple of weeks | Medium; struggles with long-running logic | Medium; flows are portable in concept, not in practice |
| BPM engine | High; licence plus specialist skills | Weeks to months | Very high; built for it | High; deep modelling lock-in |
| Bundled point tool | Marginal add-on to the host product | Days inside its lane | Low; tied to the host's artifacts | Low to medium; you leave when you leave the host |
Read that table as a set of trade-offs, not a ranking. Nothing in the bottom rows is worse than the top rows; they are answers to different questions. The mistake is picking a BPM engine for a problem the platform you already own could solve, or stretching a bundled point tool across the enterprise because it was already paid for.
The question most vendors will not ask
Before you evaluate a single external product, there is one question that decides more than any feature comparison, and almost no vendor will raise it because the honest answer costs them the deal. The question is this: is the workflow engine already inside your ERP or CMMS good enough for this process?
Most enterprise platforms shipped a workflow engine years ago. It routes approvals, enforces sequences, sends notifications, and writes to the same database as everything else. It is rarely glamorous. But it has one property no external tool can match: the process and the data it acts on live in the same system.
A second workflow engine is a second place to look
The day an approval goes missing, the first thing you do is trace it. With one engine, there is one log, one state machine, one system to interrogate. Add an external tool and every failure now has two possible homes: it stalled in the platform, or it stalled in the automation layer, or it fell into the gap between them. You have not just added a feature. You have doubled the surface you have to reason about at 2am. Prove the native engine cannot do the job before you take on that cost, not after.
This is not an argument against ever buying an external tool. Cross-system workflows, long-running processes, and anything the platform genuinely cannot model are real reasons to reach outside. It is an argument against reaching outside by default. If your automation needs sit within one system's domain, the case for using that system's own engine is strong, and it gets stronger every year the process runs. Whenever the question is which mechanism should carry the work, I would rather start from what already holds the data. My longer take on that reasoning sits in how to choose the right integration method.
The requirements people forget
Buyers write good requirements for the happy path. The flow triggers, it routes, it approves, it notifies. Demos look great because demos are the happy path. The requirements that get forgotten are the ones that only surface after go-live, when a real organisation with real people and real auditors starts using the thing. Here are the five that bite most often.
Delegation
An approver goes on leave. The whole point of automation is that the process does not wait for one person, yet a surprising number of tools have no clean way to hand an approver's authority to someone else for a defined window. It is forgotten because nobody is on leave during the evaluation. It bites the first time a payment or a permit stalls for two weeks because the named approver is on a beach.
Mobile approval
Executives and site managers approve from a phone, in a corridor, between meetings. If the approval step demands a laptop and a VPN, adoption dies and people route around the system. It is forgotten because evaluators test on a desktop. It bites when the busiest, most senior approvers quietly refuse to use it.
Audit-trail export
Who approved what, when, on what basis, and can you hand that to an auditor as a file rather than a screenshot. Many tools show a lovely history inside their own interface and offer no clean export. It is forgotten because the audit is not this quarter. It bites hard during the audit that is, when the answer to a regulator's question lives in a UI nobody outside the tool can see.
Versioning of in-flight instances
You change the process. What happens to the hundred instances already running under the old rules? Do they finish on the old version or lurch onto the new one mid-flight? Tools that quietly migrate running instances create silent inconsistency. It is forgotten because you do not change the process during the pilot. It bites the first time a live change corrupts work that was already in motion.
Integration authentication
The flow has to talk to other systems, and every one of those connections needs credentials, token refresh, and a plan for rotation. How the tool authenticates, and how gracefully it handles an expired secret, decides whether your integrations run for years or break on a random Tuesday. It is forgotten because the demo uses a personal token that never expires. It bites when that token rotates in production and every flow that depended on it fails at once. This is the same class of problem I cover in enterprise system integration explained.
Put the forgotten five in the demo script
Do not let the vendor drive the demo down the happy path. Hand them a script: delegate an approval, approve from a phone, export the audit trail to a file, change a process while instances are running, and show a credential rotating without breaking the flow. A tool that handles all five in front of you is a tool that will survive your organisation. One that fumbles them in a controlled demo will fail worse in production.
How the pricing models compare
Vendor prices are moving targets and I will not quote numbers that will be wrong by the time you read this. What is stable is the shape of the pricing model, and the shape is what determines when a tool stops being affordable. There are four common models, and each one has a volume point where it turns against you.
| Model | You pay for | Feels cheap when | Turns expensive when |
|---|---|---|---|
| Per-user | Each named person who touches the tool | A small core team builds and runs flows | Approvers scale with headcount; every occasional approver needs a seat |
| Per-flow | Each distinct workflow you publish | You run a handful of big, stable processes | You have many small flows; the count creeps and each one carries a fee |
| Per-run | Each execution of a flow | Volumes are low and predictable | A high-frequency or event-driven process fires thousands of times a day |
| Capacity | A tier of compute, connectors, or throughput | Usage sits comfortably inside the tier | You brush the ceiling and the next tier is a large, discrete jump |
The trap is matching the wrong model to your usage shape. A per-run model is a bargain for a few dozen approvals a day and a catastrophe for an integration that fires on every record change. A per-user model is fine for a builder team and brutal when every casual approver in the company needs a licence. Before you look at a single price, describe your own volume shape: how many users, how many distinct flows, how many executions, and how spiky. Then choose the model that stays cheap as that shape grows, because it will grow. If your automation is really integration in disguise, the economics shift again, which is the theme of RPA vs API integration.
Five questions to put to every shortlisted vendor in writing
Verbal answers evaporate. Written answers become part of the record you can hold them to. Send these five to every vendor still standing and read the answers as carefully as the price.
- What exactly do I own when I leave you? Can my process definitions, run history, and audit trail be exported in a documented, reusable format, and will you demonstrate that export before I sign?
- How do you handle in-flight instances when a process definition changes? Do running instances complete on the version they started on, and can I control that behaviour explicitly?
- How does an approver delegate authority, and how is that delegation recorded? Show me the audit entry a delegated approval produces.
- How do integration credentials rotate without breaking live flows? Walk me through what happens to running integrations when a secret expires or is rotated on schedule.
- Which pricing model applies to me and what is the next cost cliff? Given my stated volumes, at what point does my bill step up, and by how much?
A confident vendor answers all five plainly. A vendor who deflects, especially on the exit and the cost cliff, is telling you exactly where the pain will be.
A note on independence
This is independent, buyer-oriented guidance. It is not a paid review, not sponsored placement, and not an affiliate page. No vendor had editorial input into it, and I hold no commercial relationship with any product in the segments described. The framing reflects work delivered for clients across ERP, EAM, and CAFM environments, not a preference for any single tool.
Conclusion
Workflow automation is not one market, it is four, and the buyer feels the seams the analysts smooth over. Segment the field by what you own afterward, how fast you get value, how far the tool stretches, and what it costs to leave. Ask the question the vendors will not: whether the engine already inside your ERP or CMMS is enough. Write the forgotten requirements into the demo script. Match the pricing model to your real volume shape, not the vendor's favourite slide. And put the five questions in writing, because a promise you can hold someone to is worth more than any feature.
Do that, and you buy a system your team can run for years rather than one you spend those years working around. Automate the process you actually have, in the smallest, closest tool that genuinely handles it, and keep the number of places you have to look when something goes wrong as low as you can.
Written by Muhammad Abbas
CMMS / CAFM Manager & Enterprise Integration Specialist · 22+ years across ERP, EAM, CAFM and enterprise integration.
Work with me