Choosing an Automation Platform

Pricing models in this category change more often than the products do, and every comparison article carrying prices is wrong within a quarter.

So this page carries none. What does not date is the question of what happens when things go wrong, which is where these platforms actually differ and where comparison articles rarely look.

Seven questions. Two are disqualifying.

---

First: do you need a platform at all?

Four options, and the first two are frequently sufficient.

Native integrations. Your tools may already connect to each other directly. Fewer moving parts, no third party in the middle, and nothing extra to pay for — check before adding a platform.

Scheduled exports and imports. A weekly CSV between two systems. Unglamorous, robust, and it fails visibly. For plenty of small-business needs this is the correct answer.

A general automation platform. The connective layer, when you need several tools talking and no native path exists.

Custom code. A script on a schedule. Cheapest to run, most expensive to maintain, and it becomes a liability the moment the person who wrote it leaves.

A useful rule: platforms earn their place when you need several connections, not one. A single integration is usually better served natively or by a scheduled export.

---

The seven questions

1. What happens when a run fails? (Disqualifying)

The most important question and the one demos never show.

Ask specifically:

• Does it retry, how many times, and over what period?
• Are failed runs queued for replay, or lost?
• Can you see exactly which record failed and why?
• Can you re-run a single failed item without re-running the whole batch?

A platform that drops failed records without a replay queue will silently lose data, and you will discover it when a customer asks where their order is. This alone disqualifies a platform for anything in a critical path.

2. Does it alert on absence, not just on error? (Disqualifying for critical paths)

Error alerts catch a failure. They do not catch a break.

When a trigger stops firing entirely, nothing errors — the platform is idle, which is also what a quiet Tuesday looks like.

Ask: can it notify you when an automation that should have run has not? If it cannot, you need an external check for anything that matters, because the most common failure mode produces no error at all. Why silence is the dangerous state.

3. How does it handle rate limits and volume spikes?

Failure arrives on your busiest day, which is the worst possible timing.

Ask: what happens when the destination refuses calls — queued and retried, or dropped? And what are the platform's own limits on your plan?

4. Can you see what happened three weeks ago?

Log depth and retention.

You need to answer "why did this customer get this" long after the fact, and that question usually arrives attached to a complaint. A seven-day log makes a month-old problem undiagnosable.

5. What happens when you leave?

Automations built in a proprietary visual builder do not export in any usable form.

Ask: can you export the logic, even as documentation? If not, treat the build as unrecoverable work and factor that into how much you put there.

One specific trap: platforms that host something on your behalf — a form, a landing page, a redirect. Those stop resolving when the account closes, leaving dead links across everything you published.

6. Who authorises the connections?

Connections authorised by a personal account die when that account is deleted.

Ask: does the platform support connecting via a shared or service account, and can ownership be transferred? An employee leaving should not break your order fulfilment, and it does more often than people expect. What you are granting.

7. Where does the data go, and is any of it retained?

Every record passing through the platform passes through their infrastructure.

Ask: what is retained, for how long, where is it processed, and is it used for anything else. If you handle EU or UK personal data this determines whether you can use the platform at all, and it is a compliance question rather than a preference. Check the current requirements for your own market.

---

What not to choose on

Four things that read as differentiators.

Number of integrations. A catalogue of a thousand apps is irrelevant if the six you use are covered. Check your six.

Visual builder quality. It affects the hour you spend building and nothing about the two years you spend maintaining. A beautiful builder with seven-day logs is a bad trade.

Free tier size. It determines the first month. Check the price at the volume you expect in a year instead.

AI features. Increasingly the headline claim, and largely irrelevant to whether your data arrives. The job of this layer is reliable transport.

---

A sensible position

For a small business:

• Use native integrations wherever they exist
• Use scheduled exports where real-time is not genuinely needed
• One platform at most, for the connections that remain
• Nothing critical on a platform without a replay queue
• An external absence check on anything that would hurt if it stopped
• Connections authorised by an account that will outlive any individual
• A register of what is connected and who owns it

Then re-examine every six months rather than at every launch. This category churns, and a platform worth switching to is still worth it two quarters later.

---

Frequently asked questions

Do I need an automation platform?
Only if you need several connections and no native path exists. Check whether your tools already integrate directly first, and consider whether a scheduled export would serve — it is more robust and it fails visibly. Platforms earn their place at several connections, not one.

What is the most important thing to check in an automation platform?
What happens when a run fails: whether it retries, whether failed records are queued for replay or lost, whether you can see which record failed and why, and whether you can re-run a single item. A platform that drops failures without a replay queue will silently lose data.

Why does my automation platform not alert me when something breaks?
Because most alert on errors, and the common failure is a trigger that stops firing — which produces no error, just idleness that looks like a quiet day. Check whether the platform can notify on absence, and add an external check if it cannot.

What happens to my automations if I switch platforms?
Usually nothing transfers. Logic built in a proprietary visual builder rarely exports in a usable form, so treat the build as unrecoverable work. Watch particularly for anything the platform hosts for you — forms, pages, redirects — which stops resolving when the account closes.

Should I connect tools using my own account?
No. Connections authorised by a personal account are revoked when that account is deleted, so an employee leaving can break order fulfilment. Use a shared or service account whose ownership can be transferred.

Why doesn't this article recommend a specific platform?
Because pricing and features in this category change faster than comparison articles get updated, so any ranking here would be wrong within a quarter. The questions about failure handling, logging and exit are durable; the product list is not.