Automation tools: a map of the whole field
Beyond workflow automation: scripting, RPA, iPaaS, device and task automation, and embedded features, what each is genuinely for, and how to tell which kind your problem needs.
Rebecca Pearson10 min read
On this page
- What we'll cover
- Six kinds of automation tool
- Scripts and scheduled jobs
- Workflow and connector platforms
- Integration middleware
- Robotic process automation
- Automation inside the tools you already have
- Device and personal automation
- Choosing the right category
- The mistakes that cost the most
- Frequently asked questions
- Related reading
"Automation tools" covers a much wider field than most articles using the phrase suggest. It includes the connector platforms that get all the attention, and also scripts, robotic process automation, integration middleware, the automation features built into software you already pay for, and the scheduled jobs quietly running on a server somewhere.
These are not competing products. They solve different problems, and a good deal of wasted money comes from reaching for the familiar category when a different one was the answer. This page maps the field. For the connector platforms specifically, workflow automation tools goes into how those categories differ.
What we'll cover
Six kinds of automation tool
Before the detail, the shape of the field:
| Category | What it automates | Who operates it |
|---|---|---|
| Scripts and scheduled jobs | Anything, with code | Developers |
| Workflow platforms | Moving data and triggering actions between systems | Operators, some technical |
| Integration middleware | System-to-system data flow at organizational scale | IT and integration specialists |
| Robotic process automation | Interfaces, by imitating a person | RPA developers |
| Built-in features | Processes inside one product | Whoever uses that product |
| Device and personal automation | A phone, a desktop, an individual's own work | Anyone |
The useful question is not which is best but which layer your problem sits in. A process spanning four systems is not an RPA problem. A repeated task inside one product is rarely worth a connector platform.
Scripts and scheduled jobs
The oldest category and still the most widely used. A script does something, a scheduler runs it, and a log records what happened.
Nothing else matches it for flexibility, since a script can do anything the language can do, and there is no vendor, no subscription, and no limit on what it may connect to.
The costs are real and arrive later. A script needs somewhere to run and someone to maintain it. It knows nothing about retries, alerting, or credentials unless someone writes that too, which is most of the work. And organizations accumulate scripts on forgotten servers, written by people who have left, doing things nobody can fully describe. That is not an argument against scripting so much as an argument for knowing where the scripts are.
Reach for this when the logic is genuinely complex, when performance matters, or when a developer will own it permanently.
Workflow and connector platforms
The category most people mean by "automation tools". A trigger in one system causes steps in others, configured rather than coded.
The advance these made was removing the developer from routine integration work. Someone in operations can connect a form to a spreadsheet to a notification without writing anything, and the platform handles authentication, retries, and scheduling.
The constraint is that you work within what the platform expresses. Complicated conditional logic becomes awkward, and pricing models that charge per step can make high-volume processes expensive.
This category now includes conversational builders, where you describe the process in plain language and the platform constructs it. That changes who can build rather than what can be built, which matters most in organizations where the people who understand the processes have no route to automating them.
Reach for this when the process spans several systems and the people who understand it are not developers.
Integration middleware
Often called iPaaS, this is the enterprise end of the same idea, and it is a genuinely different product rather than a bigger version of the previous category.
The distinguishing concerns are governance rather than convenience: environment promotion from development to production, role-based access, audit trails, error queues with replay, data transformation at scale, and support commitments. The interfaces are built for integration specialists, and the pricing assumes a budget line.
Where an organization runs hundreds of integrations that regulators or auditors ask about, this is the appropriate category, and trying to run that on a connector platform eventually becomes uncomfortable. Where an organization runs eleven integrations, this is a great deal of machinery for the problem.
Reach for this when integration is a function with its own team, and failures have consequences requiring formal handling.
Robotic process automation
RPA drives software through its user interface, clicking buttons and typing into fields exactly as a person would.
Its reason for existing is systems with no API: old internal applications, some desktop software, and occasionally a supplier's portal with no other access. For those, RPA is sometimes the only option, and it genuinely works.
The costs are higher than they first appear. Automations break when interfaces change, which happens on somebody else's schedule. They are slower, since they wait for screens to render. They usually need a machine, real or virtual, to run on. And using credentials to drive a third party's website frequently contravenes its terms of service, which is worth checking before building anything a business depends on.
Reach for this when there is genuinely no API and no export, and treat it as a bridge to be removed when the underlying system is replaced.
Automation inside the tools you already have
The most overlooked category, and often the cheapest answer available.
Spreadsheet applications have scripting. CRMs have workflow rules. Project tools have automations. Email has rules and filters. Accounting packages have recurring transactions and approval routing. Chat platforms have workflow builders. Most of these are included in a subscription you already pay.
Their advantage is that they see the system's own data and events directly, with no integration, no credentials, and no separate thing to maintain. Their limitation is that they stop at the product boundary.
The practical rule is to check the built-in option first whenever a process lives inside one product. A CRM rule doing what you need costs nothing and involves no new tool. Building the same thing on a connector platform is a subscription, a credential, and another system to monitor, in exchange for capability you did not need.
Device and personal automation
Automation for one person rather than a business process: phone shortcuts, desktop macros, text expansion, browser extensions, keyboard remapping.
Easy to dismiss, and the aggregate effect is significant, because these target the small frictions that are too minor to raise as a project and add up to a noticeable share of a day. They need no approval and no budget, which is exactly why they get built.
The limitation is that they live on one device, belong to one person, and disappear when that person changes machine or leaves. Anything a team depends on should not live here.
Choosing the right category
Four questions place nearly every problem.
How many systems does it touch? One system points at built-in features. Several point at a workflow platform. Very many, with governance requirements, point at middleware.
Do those systems have APIs? If yes, almost anything except RPA. If genuinely not, you are choosing between RPA, a scheduled export, and changing the system.
Who understands the process, and can they build? If the process owner can build it directly, the automation will match the process and stay current. If it must be described to a developer, expect a translation cost on every change.
What happens when it breaks? Low consequence tolerates a script or a personal automation. High consequence needs proper error handling, alerting, and someone accountable, which favours platforms built with those included.
For the large middle of business processes, where several systems are involved and the person who understands the work is not a developer, the workflow platform category is the right answer. On CodeWords you describe the process in plain language and Cody, the automation builder, builds it, connects it to your systems, and deploys it. 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.
The mistakes that cost the most
Four recur often enough to be worth naming.
Buying a platform for a problem inside one product. The most expensive common error. Somebody wants a notification when a deal changes stage, so a connector subscription is purchased and a credential created, when the CRM has done this natively for years. Always check the built-in option first.
Using RPA where an export exists. RPA is sold as the answer to inaccessible systems, and a great many of those systems will email a scheduled CSV if asked. An automation reading that file is faster, cheaper, and does not break when a screen is redesigned.
Scripting something the business will own. A developer writes a script because it is quicker than learning a platform, which it is. Two years later the script is business-critical, the developer has moved on, and nobody in the team that depends on it can change a threshold in it.
Choosing for the pilot rather than the portfolio. The first automation is simple, so the simplest tool wins the evaluation. The tenth involves branching, exceptions, and a system with an awkward API, and by then you have built nine things on a tool that cannot express it. Evaluate against a process you expect to find difficult.
The common thread is choosing the category before understanding the problem. Ten minutes spent on the four questions above avoids nearly all of it.
Frequently asked questions
What is the difference between RPA and workflow automation?
Workflow automation connects systems through their APIs, which is fast and stable. RPA drives the user interface, imitating a person, which works on systems with no API and breaks when screens change. Use APIs wherever they exist.
Do I need more than one automation tool?
Most organizations end up with a few, and that is reasonable when each occupies a different layer: built-in features inside products, one workflow platform for cross-system processes, and scripts where developers own something complex. Running several tools in the same layer is the pattern worth avoiding, since it makes failures hard to trace.
Is iPaaS just an expensive workflow platform?
They overlap and the emphasis differs. Middleware is built around governance, environment promotion, audit, and formal support. If you need those, a connector platform will eventually frustrate you. If you do not, you are paying for machinery you will not use.
What is the cheapest way to start automating?
The features already included in software you pay for. A CRM workflow rule or a spreadsheet script costs nothing beyond the time to set it up and needs no new vendor.
How do I stop accumulating automations nobody understands?
Keep a register of what exists, what it does, what it touches, and who owns it. This sounds bureaucratic and takes about an hour to start. The alternative is discovering a critical process running on a script written by somebody who left, which is a considerably worse hour.
Does AI change which category I should choose?
It widens what workflow platforms can handle, since work involving unstructured input or judgement was previously automatable only in code. It has not changed the boundaries between the categories, and the questions above still place a problem correctly.
Where do scheduled jobs on a server fit in all this?
They are the scripting category, and they are worth singling out because they are the ones most likely to be undocumented. Every organization of a certain age has cron entries nobody can fully account for. Finding and recording them is usually the highest-value hour in any automation review.