Automation tools list: eight types and who runs each.

You came here for a list, so the list comes early: eight types of automation tool, the best-known products in each, and one line on who has to build and run the thing once it is bought. That last line is the column most lists leave out, and it decides more outcomes than any feature does.

A scope note first. This is a list of business automation tools, the kind that move data between apps, read documents, route approvals and answer routine requests. Test automation (Selenium, Cypress) and IT infrastructure automation (Ansible, Terraform) are separate categories with their own buyers, and they are left out here on purpose.

The list is sorted by type and not by brand. Products inside a type compete on price and polish, while products in different types solve different problems. Pick the wrong type and the best product in it still will not fit.

What counts as an automation tool?

An automation tool is software that carries out a repeatable step of work without a person doing it each time. It watches for a trigger (a new email, a form, a row in a sheet), applies rules, and takes an action in another system. Anything that only helps a person do the step faster, like a template or a shortcut, sits outside the definition.

The definition matters because vendors stretch it. A chat assistant that drafts a reply is useful, but someone still reads, edits and sends it, so the routine has not left anyone's desk. An automation tool is measured by the steps that now happen with nobody touching them.

The automation tools list, by type.

Each entry gives what the type does, well-known products, who builds and runs it, and when it fits. Product names are examples, listed in no ranked order.

1. Task automation and iPaaS

These connect cloud apps through their APIs: when something happens in one app, do something in another. Examples: Zapier, Make, n8n, Microsoft Power Automate (cloud flows), Workato.

• Who builds and runs it: your team. Someone maps the steps, connects accounts, and fixes the flow when an app changes a field.
• Fits when: the apps have APIs and the logic is a short chain of if-this-then-that.

The demand is real. Salesforce's MuleSoft unit reported in its 2026 Connectivity Benchmark Report, a survey of 1,050 IT leaders, that large enterprises run an average of 957 apps, with only 27% of them integrated together. Every company in that survey had more than 1,000 employees, so a 150-person firm will have fewer apps, but the share of unconnected ones tends to look similar.

2. Robotic process automation (RPA)

RPA software drives a screen the way a person would: it clicks, types and copies between windows. Examples: UiPath, Automation Anywhere, Microsoft Power Automate Desktop, SS&C Blue Prism.

• Who builds and runs it: usually a dedicated developer or a center of excellence. Bots break when a screen layout moves.
• Fits when: the system has no API, such as an old ERP screen or a government portal, and the steps never vary.

We compared the two approaches in detail in AI agents vs RPA, including why bot fleets so rarely grow past a pilot.

3. BPM and process orchestration

Business process management suites model a long, multi-person process with stages, approvals, deadlines and an audit trail. Examples: Camunda, Pega, Appian, Nintex.

• Who builds and runs it: IT or a partner, often over months. These are platforms you configure, closer to software projects than to apps.
• Fits when: the process crosses departments, has formal approval rules, and a regulator or auditor wants to see every step.

4. Document processing (IDP)

Intelligent document processing reads PDFs, scans and emails, pulls out the fields, and checks them against rules. Examples: ABBYY Vantage, Rossum, Google Document AI, Azure AI Document Intelligence.

• Who builds and runs it: your team or an integrator. Someone has to train the extraction, set confidence thresholds and handle the exceptions queue.
• Fits when: the bottleneck is people retyping documents into a system, whether that is purchase orders, delivery notes or claims forms.

5. Automation built into apps you already own

Most business software now ships its own workflow features. Examples: HubSpot workflows, Salesforce Flow, monday.com automations, Microsoft 365 and Google Workspace rules and scripts.

• Who builds and runs it: the app's admin.
• Fits when: the whole routine lives inside one system. It stops fitting the moment the routine needs a second app.

6. Marketing and sales automation suites

These run campaigns, lead scoring and follow-up sequences. Examples: HubSpot Marketing Hub, ActiveCampaign, Klaviyo, Outreach.

• Who builds and runs it: a marketing ops or sales ops person.
• Fits when: the routine is outbound communication to customers or prospects, at volume, on a schedule.

7. AI agent builders

Agent builders let you assemble an AI model, instructions and tools into an assistant that takes actions. Examples: Salesforce Agentforce, Lindy, Relevance AI, and the AI steps inside Zapier, Make and n8n.

• Who builds and runs it: your team, plus someone who tests the agent's answers and watches for drift.
• Fits when: a step needs judgment over messy text, like sorting inbound requests or summarizing a thread.

AI adoption is still early in most firms. The US Census Bureau's Business Trends and Outlook Survey found overall business AI use hovering between 17% and 20% from December 2025 to May 2026, rising to 37% among firms with 250 or more employees.

8. Managed automation services

Here you buy the finished automation and someone else builds and operates it. This type includes freelancers and agencies who build on the tools above, and managed services that build, run and maintain the routines for as long as you pay.

• Who builds and runs it: the provider.
• Fits when: you know which routines cost you hours but nobody on staff has the time or the skills to own a build.

Uplift sits in this group. A customer explains the routine the way they would to a new hire, and our team turns it into a working agent, operates it, and repairs it whenever a connected app changes its fields or its API. Each build is about 95% tested code with AI used only where code cannot do the step, an approach laid out on how we build. For teams that do not yet know what to hand over, the Brainstormer looks at each role and suggests what is worth automating, drawing on over 14,000 real-world automations. Pricing is a flat package of agents with no tokens, no per-seat licenses and no meter, and the whole organization gets access. Details are on the product page.

Our model has a cost, and it belongs in this list too. You do not end up owning a codebase, and the automations stop when the plan does. If your company wants an asset it holds after the contract ends, a development shop, or an iPaaS your own staff operates, is the better purchase. Agencies sit in between; we looked at that trade-off in AI automation agencies. Whichever you pick, ask the supplier in writing what happens to the automations, the data and the documentation on the day you leave.

Which of these does your company already own?

More than most teams expect. Okta's Businesses at Work 2025 report found its customers use an average of 101 apps, and that count only includes apps run through Okta's sign-in. Several of those apps will have type-5 automation switched off and unused.

Zylo's 2026 SaaS Management Index, built from more than 40 million licenses it tracks, found organizations leave 36% of their SaaS licenses unused while adding an average of 21 applications a month. Buying another automation tool adds to that pile unless someone is ready to operate it.

So the first pass through any automation tools list should be an inventory. List the routines that eat hours, then check whether a tool you already pay for covers each one. In a lot of companies the honest answer for the first two or three routines is a setting nobody switched on.

Why do automation tools so often leave the work in place?

Because a tool only removes work after someone builds the automation, and seven of the eight types leave that job with you. In Eagle Hill Consulting's 2025 Technology Enablement Survey of 1,436 US employees, 64% believed automating repetitive tasks would raise their productivity, yet only 38% said automation had removed tedious tasks in the past year. Just 20% said their organization had improved its automation at all.

Those two figures count the same people, which is what makes the gap useful. The belief is there and the tools are there. What is missing is the hours to design, test and look after each routine, and those hours compete with the very workload the automation was meant to cut.

A smart skeptic would answer that this is a staffing problem and that hiring an automation engineer solves it. For a company with dozens of routines and the budget for a permanent role, that is a sound answer. For a 100-person company, one hire becomes a single point of failure, and the routines stall the week that person leaves. Handing every employee a no-code tool is like buying everyone a fishing rod: most of the rods stay in the closet.

The work being lost is spread thin, which makes it easy to ignore. A Talker Research survey commissioned by Grammarly of 2,000 US knowledge workers counted an average of 53 tasks a week that break people's focus, and more than three and a half hours of lost productivity weekly. Grammarly paid for the study, so treat it as one data point. The pattern it describes, dozens of small interruptions a week, is the kind of work our list of business process automation examples is built around.

How do you choose the right type?

Start from the symptom. Find the step where a person is acting as glue between systems, describe what kind of glue it is, and the type usually follows.

Then ask the question the table cannot answer: who on your side will open this automation when it breaks? Put a name next to each routine. If the honest answer is "nobody", that rules out every type except the last one, however good the product.

What a list like this cannot tell you.

No list can tell you which routine is worth automating first, and that decision moves the result more than the choice of tool. A great product pointed at a routine that runs twice a month saves almost nothing.

Here is a rule you can apply with no vendor in the room. Write down every routine your team repeats at least weekly, estimate the minutes per run, and multiply by runs per month. Rank by total hours. Then take the top three and, for each, note whether the steps ever vary and how many systems they touch. Routines with fixed steps inside one or two systems go to built-in automation or iPaaS. Routines that touch many systems, or that need judgment, are where the choice of who builds and runs it starts to matter more than which tool.

The rule has a limit it cannot fix. It ranks the routines people already know about, and teams are usually poor at spotting the work they have stopped noticing. If the ranked list comes back short, the gap is more likely in the inventory than in the business.