Workflow automation for enterprise: rollout, not procurement
Large organizations rarely fail at choosing a platform. They fail at who may build, what happens to the automations people already made, and who owns it in year three.
Rebecca Pearson11 min read
On this page
Large organizations run thorough platform evaluations and then get poor results anyway. The evaluation is rarely where it goes wrong. What goes wrong is everything afterwards: who is permitted to build, what happens to the several hundred automations people already made without asking, and who owns the estate once the project team has moved on.
This page is about that half. For comparing the platforms themselves, see best iPaaS platforms and workflow automation platform.
What we'll cover
The shadow estate you already have
Before selecting anything, find out what is already running. It will be more than anyone expects.
Every large organization has automations nobody sanctioned: spreadsheet macros running month-end, a script on a laptop under someone's desk, mail rules doing triage, a personal automation account holding credentials to four production systems, and a process that only works because one person in finance runs it every Thursday.
Why this matters before procurement: the new platform's business case is usually built on processes that are already automated badly. If you do not know what exists, you will buy a platform, migrate the visible work, and leave the risky work exactly where it is.
How to find it without making people defensive. Ask what people would have to do by hand if their laptop died. That question produces honest answers; "are you running any unapproved automations" does not.
Expect three categories. Things that are genuinely important and should be rebuilt properly. Things that duplicate each other because three teams solved the same problem. And a meaningful proportion that nobody has used for months, which can simply be switched off.
That inventory is the most valuable artifact of the whole programme, and it is the step most often skipped because it produces no visible progress.
Deciding who may build
The decision with the largest consequences, and the one most often left to default.
Central IT only produces consistent, well-built automations and a queue. The business processes that would benefit most are owned by people whose requests sit behind higher-priority work. They do not wait; they build in spreadsheets instead, and the shadow estate grows.
Anyone at all produces volume quickly and a mess within eighteen months: duplicated workflows, nobody sure which is authoritative, credentials scattered, and a critical process built by someone who has left.
The arrangement that survives is a boundary rather than a rule. People may build freely within their own team's systems and data. Anything touching customer data, finance, or another team's systems goes through review. A small central group owns shared connections and keeps the register.
Whichever you choose, the platform must be able to express it. A tool where every user is effectively an administrator cannot implement your policy however carefully it is written, and this is worth testing during evaluation rather than assuming.
The second-order effect worth planning for: if you permit business users to build, they will need somewhere to learn. A programme that grants access without training produces exactly the mess the sceptics predicted, and then gets cancelled.
The centre of excellence, and how it fails
The standard recommendation, and it fails in three predictable ways.
It becomes a build queue. Formed to enable others, it ends up building everything itself because that is faster than teaching. Two years later it is a small development team with a backlog, which is what it was meant to prevent.
It becomes a review board. Every automation requires approval, approval takes three weeks, and people go around it. Governance that is slower than the workaround produces less governance, not more.
It has no authority. A team responsible for standards with no ability to require anything, watching business units buy their own tools.
What works instead, where it works: owning the platform, the shared connections, the register and the standards; providing training and templates rather than building on request; reviewing only what crosses the boundary that actually carries risk; and having enough authority to say no to a second platform.
The measure of whether it is working is not how many automations it has built. It is how many other people have built automations that meet the standard.
Making the sanctioned route the fast route
The single most effective governance intervention, and it is not a control.
People build shadow automations because the approved path is slow. Adding more approval steps makes that worse. The route out is making the approved path faster than the workaround.
Pre-approve the common connections. If connecting to the CRM requires a ticket, people will export to a spreadsheet instead. Shared, governed connections that anyone permitted can use remove the most common reason to go around the system.
Publish templates for the recurring shapes. Approval routing, document generation, data sync between two named systems. Most requests are variations on a handful of patterns.
Make the review proportionate. Something touching only one team's own data does not need the same scrutiny as something writing to the finance system. A single review standard applied to everything is either too heavy for the small cases or too light for the large ones.
Reduce the translation cost. The slowest part of the approved route is usually that the person who understands the process has to explain it to someone who can build it, and that person is busy. Where the process owner can build directly, the queue disappears rather than shortening. On CodeWords a person describes the process in plain language and Cody, the automation builder, builds it, connects it to the approved systems, and deploys it, which removes the translation step that creates the queue in the first place. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What auditors will ask
Worth knowing in advance, because these are difficult to retrofit.
Who can access this data, and how is that enforced? Role-based access, demonstrable rather than described.
What changed, when, and who changed it? Change history on automations, with rollback.
Where is data processed and stored? Region matters under several regimes, and not all platforms let you choose.
What third parties are involved? Every connector is a data flow to somebody, and the full list is usually longer than anyone expects.
How long is data retained? Execution logs frequently contain the data that passed through, which means your retention policy applies to them.
Can you evidence that the control operated? Not that it exists, but that it was working throughout the period. This needs logging that survives long enough to prove it.
What happens when the person who built this leaves? Ownership recorded as a field rather than as institutional memory, and credentials on service accounts rather than personal ones.
If you face any formal compliance regime, put these to prospective vendors before the technical evaluation, because they eliminate candidates faster than features do.
Measuring whether it worked
Most automation programmes report the wrong numbers, which is why they struggle at renewal.
Automations built measures activity, not value, and rewards building things nobody needed.
Hours saved is usually an estimate multiplied by an assumption, and everyone in the room knows it.
What is worth measuring: how long a business process now takes end to end, compared with before. How many processes have an owner and a written description. How many automations run on personal credentials, trending toward zero. How many people outside IT have built something that met the standard. And the size of the shadow estate, re-inventoried annually.
That last one is the honest measure of a governance programme. If unsanctioned automation is still growing, the approved route is still too slow, whatever the dashboard says.
A rollout order that works
Not a project plan, but the sequence that avoids the usual failures.
Inventory before you procure. Find the shadow estate first. It changes the business case, it reveals which processes actually matter, and it stops you buying a platform sized for the work you can see rather than the work that exists.
Pick one business unit, not a pilot across many. A pilot spread thinly proves nothing and satisfies nobody. One unit, taken properly to production, teaches you what your standards should say and gives you a reference that other units will believe.
Write the boundary down before granting access. Who may build what, against which systems, with what review. Doing this after people have started means retrofitting rules onto work already done, which is where programmes acquire their reputation.
Migrate the low-consequence things first, so the team learns on work that can afford a mistake. Moving payroll first is how a rollout becomes a cautionary tale.
Set a date to decommission what you replaced. Migrations that run indefinitely leave two systems running, and the old one quietly becomes permanent because nobody owns turning it off.
Re-inventory annually. The shadow estate is the honest measure of whether the sanctioned route is fast enough, and it is the number worth reporting.
Frequently asked questions
Should we allow business users to build automations?
Within a boundary, yes, because the alternative is not less automation but less visible automation. Let people build within their own team's data, require review for anything crossing into customer, finance or another team's systems, and provide training rather than only permission.
How do we handle the automations people have already built?
Inventory first, without blame, then sort into rebuild, retire and leave alone. Expect a meaningful share to be unused. The inventory usually justifies the exercise on its own, and it is the step most often skipped.
Do we need an iPaaS or will a workflow platform do?
It depends on whether you need environments, change control, replayable error queues and role-based access. If audit asks you those questions, you need the heavier category. If nobody has ever asked, you would be buying capabilities that stay switched off.
How long does an enterprise rollout take?
Months for the platform, considerably longer for the governance and culture. The pattern that works is starting with one business unit and a small number of real processes rather than a company-wide launch, because the first unit teaches you what your standards should actually say.
Who should own the platform internally?
A small group spanning IT and the business, accountable for it working and close enough to operations to know which processes matter. Pure IT ownership tends toward a queue; pure business ownership tends toward a mess.
What is the most common reason these programmes stall?
The approved route being slower than the workaround. Every other failure follows from that, including the shadow estate, the frustrated business units and the centre of excellence that became a build queue.
How do we stop buying three platforms?
Decide the boundary early and enforce it at procurement rather than afterwards. The common pattern is IT buying an integration platform while marketing and sales each buy their own workflow tool, which is defensible if deliberate and expensive if accidental.
Should the platform be centrally funded or charged back?
Central funding gets adoption; chargeback gets discipline. The arrangement that tends to work is central funding for the platform and shared connections, with business units carrying the cost of their own heavy usage. Charging for the entry cost suppresses exactly the experimentation you were trying to encourage.
What do we do about teams that already bought their own tool?
Find out why first, because the answer is usually that the central route was too slow, and that is information rather than misbehaviour. Consolidate where the overlap is genuine, and be willing to leave a team on a specialist tool that does something yours does not. Forcing consolidation for its own sake creates the next shadow estate.