Somebody has told you the answer is Power Automate. Possibly your IT support, possibly a consultant, possibly a webinar. It might be right. It is worth knowing that it is one option rather than the option, because the assumption costs money that never shows up as a line item.
The honest position is that automation is a thing you can buy in several places, and which one fits depends less on the task than on how many people touch it and what you already pay for.
Where the assumption comes from
Most Irish small businesses already pay for Microsoft 365. It is on the bill, it is already trusted with the email, and the tools appear in a menu people have seen for years. Reaching for something already paid for is sensible instinct.
The other half is who gets asked. A Microsoft partner recommends Microsoft, in the same way a roofer recommends a new roof. Not dishonestly, mostly. It is what they know and what they are good at, and their good work looks like Microsoft work because that is the work they do.
When staying inside Microsoft 365 is clearly right
- The data already lives there. If the process runs on SharePoint, Outlook, Teams and Excel, an automation that stays inside that boundary has no integration work to do and no permissions to reinvent.
- It touches personal data and you need the governance. Retention, audit, access control and data residency are answered by the platform rather than by you.
- Staff need to change it themselves. Someone non-technical can open a flow and adjust a condition. That is genuinely valuable and it is rare outside the big platforms.
- It has to survive you. Any Microsoft partner in the country can pick up a Power Automate flow. Fewer can pick up a bespoke application.
That last one is underrated and it is a real argument. Boring and widely understood beats clever and unique for anything a business depends on.
When it is the expensive answer
When the licence count is the real cost. Microsoft’s automation tooling is licensed per user or per flow, and the sums change shape as more people touch a process. A workflow used by three people and a workflow used by thirty are the same build and very different bills. It is worth doing that arithmetic before the build rather than after, because it does not get cheaper later.
When the people involved are not staff. Customers, suppliers, applicants, members. They do not have licences and should not need them. Anything public-facing pushes you toward something that lives on the open web instead.
When the job is genuinely small. A script that runs at six every morning, tidies a file and emails two people is not a platform problem. It is twenty lines of code and somewhere to run it, and dressing it as an enterprise workflow adds cost and ceremony to something that should be invisible.
When the tool already exists and costs twenty euro a month. Plenty of processes are solved outright by software somebody else maintains. Building that yourself, on any platform, is the expensive way to arrive at a worse version.
What the alternatives actually are
Not “custom software”, which sounds like a project with a steering group. In practice, three things:
- An off-the-shelf tool. Someone has already built it and charges a subscription. Cheapest by a distance when it fits.
- A workflow tool outside Microsoft. The same connect-this-to-that idea, priced by how much runs rather than by how many people watch it.
- A small application on ordinary hosting. A web page, a database, a job that runs on a schedule. Sounds heavier than it is, and it has no per-person cost at all.
The last one is the least understood and the one most often dismissed as overkill for a small business. It usually is not. There are real reasons not to build, and cost per user is rarely one of them.
Three situations, worked through
Approvals for six office staff, on SharePoint already. Stay in Microsoft. The data is there, the people are licensed, and someone internal can adjust it later. Anything else is contrarianism.
A booking form for the public that writes into a schedule. Leave Microsoft. The people using it are not staff, do not have licences, and should never see a sign-in prompt. A small web application, or an existing booking product, will be cheaper and better.
A nightly job that reconciles two files and flags mismatches. Nobody uses it. It is not a workflow, it is a scheduled task, and it wants somewhere quiet to run rather than a platform.
The question that decides it
Who touches this, and are they on your Microsoft bill?
If the answer is a handful of licensed staff, staying inside is usually right and usually cheapest. If it is thirty people, or anyone outside the business, the arithmetic starts moving and it keeps moving for as long as the thing exists.
Second question, half as important and twice as often skipped: does this already exist as a product? The cheapest automation is the one somebody else maintains.
Five things worth doing
- Count the people who will touch it, including the ones who only look. That number drives more of the cost than the build does.
- Check whether anyone outside the business is involved. If so, most platform answers are already the wrong shape.
- Search for an existing product first, properly, for an hour. It is the cheapest hour in the whole exercise.
- Ask whoever is quoting what the licence position is at your headcount, in writing. A vague answer is itself an answer.
- Ask who else could maintain it. If the honest answer is nobody, that is a cost, whichever platform it was built on.
Common misconceptions
- “We already pay for it, so it is free.” Your existing subscription covers a lot, and automation beyond a certain point is licensed separately. Free until it is not.
- “Custom means expensive.” Custom means bespoke, which is a different word to expensive. A small application can cost less than three years of licences for the same process.
- “Anything outside Microsoft is a security risk.” Where something runs matters far less than who can reach it and what happens to the data. That is a question to ask in both directions.
- “We have to pick one and stick to it.” Most businesses end up with both, and that is fine. The failure is not mixing, it is never asking.
The honest summary
If your process runs on data already sitting in Microsoft 365 and the people involved are staff, stay there. It is the right answer more often than not, and this is not an argument against it.
It stops being the right answer when the licence count is doing the work, when the people involved are not on your payroll, or when the job is small enough that a platform is heavier than the problem.
The useful habit is asking the question at all, before the build rather than after the first renewal. If you have something in mind and want a straight read on which side of that line it falls, describe what happens today and who is involved. The answer is often that an existing product already does it, which is a cheaper thing to be told early.
Common questions
Is Power Automate included in Microsoft 365?
Some of it. Standard business subscriptions include automation using the everyday Microsoft connectors, and there are separate licences for premium connectors, business data and higher volumes. The line is easy to cross without noticing, so it is worth asking where you sit before building rather than after.
Can customers use something built in Power Apps?
Not straightforwardly. Anything aimed at people outside your organisation is a different licensing and access question, and it is usually the point at which an ordinary web application becomes both simpler and cheaper.
Is a custom application harder to look after?
Sometimes, and it depends far more on how it was built than on whether it is custom. The fair question to ask anyone quoting is who else could maintain this if you disappeared. Ask it about a Power Automate flow too, because the answer is not automatically better.
What if we have no Microsoft 365 at all?
Then the question answers itself, and buying a platform in order to automate one process is rarely worth it. An existing product or a small application will almost always be the cheaper route.