Somebody in your business spends an hour a week copying the same information from one place to another, and everybody agrees it ought to be automated. Then the questions begin: a script, a drag-and-drop tool or proper software? The wrong answer hurts a year or so later, when the person who built it has moved on, the thing has quietly stopped and nobody can say what it did.
We’re a technical consultancy and not a software agency, so our starting point is to choose the smallest tool that does the job and to be honest about who’ll look after it.
Questions that settle it before you look at tools
How often the task runs and how many people touch it comes first. A weekly task for one person can live with a rough tool. Something that runs hundreds of times a day, or that several people set off at once, needs a tool that copes with two things happening together and tells somebody when one goes wrong.
What the task has to reach is the question that most often decides things. Some systems offer an API, which is a defined way for one piece of software to talk to another, and many have a connector, a ready-made link between two named products, in the common automation tools. A system with only a screen and a person clicking is much harder, because anything that mimics the clicking breaks when the screen changes. Ask the supplier what they offer first.
Two questions get skipped. What happens when it fails, and how long before anyone notices? A failed copy of a mailing list is an annoyance, while a failed payment run is not. And who owns it afterwards, meaning the person who’ll fix it in a year when its author is on leave or has left? If the honest answer is nobody, that favours the simplest option or waiting. Looking after it is the kind of routine continuing support is arranged around, but somebody has to be named.
Think about the data too, and the money. Information passes through the tool, so you need to know who can see its logs and where each system’s password is stored. A script costs little to run but needs someone to maintain it, and a bespoke application costs most to start and still needs hosting and upkeep. Check how any tool you’re considering is priced, and whether that changes as more people or flows use it, before you commit. Lock-in belongs in the same sum: how hard would it be to move your logic elsewhere, and could you even see it written down?
What each route is good at, and where it bites
A script is a short program written for one job, run by hand or on a schedule. It’s cheap and flexible, and suits a technical person automating something technical. The risk is that it lives on one machine, in one person’s head, with a password written into it. With no screen, nobody sees it stop.
A low-code flow is built by joining ready-made steps in a visual tool, and Microsoft’s Power Automate is one example. It suits tasks between systems that already have connectors, and a non-programmer can often follow it. Its limits are rules about the platform rather than your design, so read them first. As at August 2025, Microsoft’s limits page says that a cloud flow whose trigger or actions fail continuously will be turned off, with 14 days given as the period. A flow that isn’t triggered for 90 days might be turned off too, and owners and co-owners are notified 30 days before.
Licences come into it as well. Flows owned by users with premium licences (a paid tier the page doesn’t define) or assigned capacity licences (it names Power Automate Process, per flow) aren’t subject to that 90-day suspension, and running a flow that uses a custom connector needs a premium or trial licence. A flow also uses its owner’s plan, and if the owner leaves the organisation the flow reverts to the Low performance profile, which is a lower tier of request allowance.
In practice that means a flow can stop for reasons that have nothing to do with your business. A quarterly or yearly task may be switched off between runs, and the warnings go to the flow’s owners and co-owners, so if the only owner has left and nobody else is a co-owner they may reach no one who’s watching. Microsoft’s page doesn’t say what happens to notifications when an owner leaves. Before you rely on a flow, check who owns it and which licence it runs under, and for anything important we’d name a second owner.
A bespoke application is real software with its own screens, rules and storage. It earns its cost when the task is central to how you work, when many people use it, when you need a record of who did what, or when nothing off the shelf fits. It’s also the route that needs the most looking after for the longest, so if you’re unsure which side of the line you’re on, a short feasibility check before any building starts is the sensible first step. Where an application is the right answer we can scope bespoke integrations, prototypes and applications, with the scope agreed before work starts.
A made-up example
This one is invented, to show how the questions work. A small architectural practice receives supplier invoices as PDF attachments. Each week, its office manager saves about forty of them to a folder and types the supplier, date and amount into a spreadsheet for the accountant.
The invoices arrive by email and the folder lives in cloud storage, and both have ready-made connectors, so a flow could do the saving. A script would need someone technical to own it, which the practice lacks, and an application is more than forty invoices a week deserve. Failure matters moderately, because a missed invoice delays a payment, so the flow should email the office manager and a named colleague when it fails. The office manager keeps typing the amounts herself, because reading figures off PDFs is a separate and harder job than saving them. The practice chooses a flow, writes one page on what it does and who owns it, and sets a quarterly reminder to check it still runs.
Start smaller than you think you need to
Write down the manual process first, odd cases included. That page is the specification for any of the three routes, and it can show a step can be dropped. Then automate the least risky step, run it alongside the manual way for a few weeks and compare results before you let it replace anything. A small prototype that proves a connection works is cheaper than finding out halfway through a build that it doesn’t.
If the task is about drafting or summarising text rather than moving information between systems, that’s a different question, and our post on AI for business productivity covers it.
If you’ve got a repeated task in mind and a suggestion or quote already on the table, write to us with what the task touches and who’d own it afterwards, because those two answers often settle more than the choice of tool.