For a few years now, Microsoft has been selling Power Automate and Power Apps as "no-code", "free with Microsoft 365" and "democratising automation". In real-life SMEs that sometimes works beautifully, and sometimes leaves behind tech debt that no one wants to touch. The difference isn't the tool — it's what gets built, and by whom.
Power Platform is today the most common shortcut to automation in small and mid-sized companies. Rightly so — for many simple processes it's exactly the right level of tool. This piece is about where that shortcut actually reaches the destination, and where it ends in a dead-end at €180 a month.
What you actually get "in the box"
Power Automate (formerly Microsoft Flow) is an automation engine — it moves data between apps and triggers actions on events. Power Apps is a builder for simple form-based applications that run in a browser or on a phone. Both are part of the broader "Power Platform" family (which also includes Power BI and Copilot Studio).
Most Microsoft 365 Business plans give you a so-called seeded license — a limited version of both tools. You can build flows on "standard" connectors (Outlook, SharePoint, OneDrive, Teams, Excel Online, Forms). You can build a Power App for users who have an M365 license. That's it. And "that's it" is enough more often than people think.
Anything that needs premium connectors (SQL Server, any REST API through a Custom Connector, Dataverse, a bank connector) requires a license per user or per flow. That's where the real costs start, which I'll come back to.
When Power Automate makes sense
The best flows in SMEs are the ones that link things that already live in the Microsoft environment. Three examples we see regularly and that actually pay back the time invested:
- An invoice lands by email from a supplier → a flow saves it in SharePoint, in the folder for that supplier, extracts the number and amount (AI Builder for scanned PDFs) and pings the bookkeeper in Teams.
- An employee fills in a leave request in Microsoft Forms → a flow creates an approval task for the manager in Teams, after approval updates a SharePoint list and emails HR.
- Every morning a flow pulls the bank balance from a sheet, compares it to the budget in Excel and sends the board a one-line message with three numbers.
What they have in common: everything lives inside Microsoft 365, there's no production SLA, and a failure won't stop the warehouse. These are ideal candidates for the seeded license — "free" in quotes, because you already paid for it in your M365 subscription.
For one of our clients — a 14-person transport and forwarding company from western Poland — we built exactly that kind of flow for invoices from carriers. Before, the bookkeeper spent about 6 hours a week sorting them and keying them into enova365. After: 1.5 hours. Build cost: one consultant-day plus two half-days of fixes in the first month. A year later the flow still runs, though one connector needed a patch when Microsoft changed an API.
When Power Apps makes sense
Power Apps shines where a team needs a simple screen to capture or look at data, but pulling an off-the-shelf CRM or WMS is too much, and Excel is too little. Concrete places where it works:
- A "service report" form for field technicians who used to scribble on paper and re-type it in the evening at the office.
- A "what needs doing today" list for shop-floor foremen, backed by a SharePoint list.
- A simple stock-take app that uses the phone camera as a barcode scanner (Power Apps supports this out of the box).
Anywhere someone is currently typing data into Excel and then re-typing it into another system, a Power App with a decent form and SharePoint behind it is often enough. No developer, no server, no three-month rollout.
What Power Platform can't do without pain
Power Platform is not a substitute for a real application. Three places where people regularly come unstuck:
- High throughput. A flow has daily execution limits, depending on the license. If you try to push 10,000 events a day, you'll get throttled and the flow will start losing data. This is not a tool for EDI or for real-time integration between production systems.
- Branching business logic. A flow with 40 steps, 15 conditions and a loop over a list is practically impossible to maintain. We've seen them. Maintaining them costs more than writing the same logic in C# or Python.
- Critical ERP integrations. If a flow mistake means a delivery note goes to the wrong customer or a database write goes out of sync — not here. Power Platform has no real transactionality, retries are limited, and debugging is slow.
The line is simple: if the flow fails overnight and no one notices until morning, it's a good candidate for Power Automate. If the flow fails overnight and at 7 a.m. you've got a problem with your delivery to the retail chain — build it differently.
The licensing trap
This is the single most common slip we see. Someone builds a flow on the seeded license, everything works, they're proud. Then they need to add a SQL Server connector or a Custom Connector to the bank's API. Microsoft instantly asks for Power Automate Premium per user (roughly €15–20 per user per month) or Per flow (roughly €100 per flow per month). For ten people using that flow it suddenly costs €150–200 a month.
That's the moment to do the maths. How many hours per week does the flow actually save, and for how many people? If it saves four hours a week for one person — €200 a month is worth it, because the loaded hourly cost of an admin worker is well above that. If it just "looked nice in the demo" — that €200 might be better spent elsewhere.
One more thing: Microsoft 365 and Power Platform prices go up roughly once a year. Any 3-year plan needs to be priced with a buffer.
Who builds it, and what happens when they leave
Here's the second classic trap. In SMEs, Power Automate is usually built by "the one who's good with Excel" — often someone from accounting, HR or customer support. Everything works, the team's proud, IT doesn't even know it exists. Then that person changes jobs, and a flow with 40 steps that no one else understood becomes someone else's problem.
The fix isn't to ban it — it's three rules:
- Every flow is owned by a "service account", not the author's personal mailbox. The author leaving then doesn't kill the process.
- Every flow has a one-page description: what it does, what triggers it, what happens if it fails. Stored in SharePoint, not in the author's head.
- A short review every six months: does the flow still run, would anyone build it the same way today, is it still worth it.
How to start without messing it up
Practical first step: find one process in your company where someone clicks the same thing for an hour every week. It could be moving invoices, merging reports, sending weekly reminders. Build a flow for it in a single day — on the seeded license, no premium connectors. If it works, do the next one.
Don't start with "let's digitise the whole purchasing process". Start with one email, one report, one form. They add up.
If you're not sure which process in your company is worth touching first — or you've already got 15 flows and no one knows which of them still run — instead of guessing, let's talk. The first call is free and takes half an hour.
Power Platform won't replace a solid integration. But if the process is simple, the data lives in Microsoft 365, and a failure won't stop the warehouse — this is exactly the right tool.