Power Automate is Microsoft’s workflow automation tool, bundled into most Microsoft 365 plans, that lets you build flows to handle repetitive admin — routing emails, saving attachments, chasing approvals — without writing code. For Melbourne SMEs already paying for Microsoft 365, much of it costs nothing extra. The catch is knowing where the free use rights stop.
Every business runs on small, dull tasks done by hand: copying form responses into a spreadsheet, filing invoices, pinging the team when a particular email lands. Power Automate takes that work off your staff. This post covers what it does, the licensing reality nobody warns you about, cloud flows versus desktop automation, the governance traps that bite when staff leave, and when you are better off hiring a developer instead.
What Power Automate actually is
Power Automate is part of the Microsoft Power Platform, alongside Power Apps and Power BI. At its core it is a trigger-and-action engine: something happens (a trigger), and it carries out a sequence of steps (actions) in response. “When an email arrives from a client with an attachment, save it to SharePoint and post a message in Teams” is a complete, useful flow — built by clicking through a designer, not by writing code.
It connects to hundreds of services through connectors. Outlook, Teams, SharePoint, OneDrive, Excel, Forms and Planner are the Microsoft ones most SMEs use, but there are connectors for Dropbox, Salesforce, SQL databases and more. The connector lets a flow read and write data in each service on your behalf.
The licensing reality
This is where most advice online falls apart, because it either pretends everything is free or scares you off entirely. The truth sits in between.
Most Microsoft 365 business and enterprise plans include seeded Power Automate use rights. That means you can build and run cloud flows using standard connectors — the Microsoft services you already pay for: Outlook, Teams, SharePoint, OneDrive, Excel, Forms, Planner. For a large share of genuinely useful SME automations, that included entitlement is all you need, at no extra cost.
You start paying extra the moment you cross one of three lines:
- Premium connectors. Connecting to a SQL database, Salesforce, an HTTP API or many third-party systems requires a premium licence. The designer marks these “Premium”, so you find out before you build.
- Per-flow plans. Licence a single business-critical flow that many people rely on, rather than every user. Sensible when one flow serves a whole department.
- Per-user plans. Licence specific staff who build and run many premium flows. Sensible for a power user or a small automation team.
The practical rule: scope early automations to standard Microsoft connectors and you will likely stay inside what you already pay for. Microsoft reshuffles plan names and inclusions regularly, so confirm the current entitlements against your specific subscription before assuming a flow is free. Our Microsoft 365 team checks this before building anything that might trip a licence.
Cloud flows versus desktop flows (RPA)
Power Automate comes in two flavours, and confusing them leads to building the wrong thing.
| Aspect | Cloud flows | Desktop flows (RPA) |
|---|---|---|
| Where it runs | In the cloud, on Microsoft’s infrastructure | On a Windows machine, driving the desktop |
| What it automates | Modern apps with APIs and connectors | Legacy apps, desktop software, websites with no API |
| How it works | Triggers and actions through connectors | Records and replays clicks, keystrokes, screen actions |
| Reliability | High — talks to apps the proper way | Fragile — breaks when a screen layout changes |
| Typical use | Email, Teams, SharePoint, approvals, forms | Pushing data into an old accounting or line-of-business system |
Cloud flows are what most SMEs should reach for first; they are reliable because they talk to applications through proper interfaces. Desktop flows — Microsoft’s robotic process automation, or RPA — automate the screen itself, mimicking a human clicking through a Windows program. They are useful for old line-of-business software that has no API, but they are brittle: change a button’s position or a field’s name and the flow breaks. Treat RPA as a last resort for systems you cannot reach any other way, not a default.
Common SME automations worth building
These flows deliver real time savings without exotic licensing, and none need a developer to maintain once set up properly.
- Email-to-Teams alerts. When an email lands in a shared mailbox from a key client, or with a matching subject, post a card in the relevant Teams channel. Stops important messages drowning in an inbox.
- Approval workflows. Leave requests, purchase orders, expense sign-offs. The requester fills a form, the approver gets a Teams or email prompt with Approve and Reject buttons, and the outcome is logged. No more chasing managers for a yes.
- Save attachments to SharePoint. When invoices or signed documents arrive by email, file the attachment in the correct SharePoint library automatically and consistently named. Ends the “where did that PDF go” hunt.
- Form-to-spreadsheet. A Microsoft Forms submission drops straight into an Excel table or SharePoint list — bookings, incident reports, supplier details — with no manual re-keying.
- New-client onboarding. One trigger kicks off a sequence: create the SharePoint folders, generate a Planner task list, send the welcome email, notify the account manager in Teams. A checklist people forgot half of becomes one reliable flow.
A construction firm in Box Hill we work with was losing supplier invoices that arrived in a shared mailbox and got buried. We built a cloud flow that saved every invoice attachment to a dated SharePoint library and posted a notification to their accounts channel. It used only standard connectors, so it ran inside their existing licensing, and it removed a recurring source of disputes with subbies over unpaid invoices. That is the shape of a good first automation: narrow, boring, previously done by hand.
The governance and security angle
This is the part MSPs care about and most “just build a flow” tutorials ignore. A flow runs with someone’s permissions, often unattended, sometimes touching sensitive data. Left ungoverned, it becomes a liability.
Flow ownership when staff leave
Here is the scenario that catches businesses out. A capable staffer builds a dozen flows under their own account, then resigns. You disable their account during offboarding, and every flow they owned silently stops — invoices stop being filed, approvals stop routing, and nobody knows why. Critical flows should be owned by a shared service account or have co-owners, never tied to one person’s personal login. Offboarding should include checking what a leaver automated.
Data loss prevention policies
Power Automate moves data between services, which means it can also move data out of places it should stay. Microsoft’s data loss prevention (DLP) policies in the Power Platform admin centre classify connectors as business or non-business and block flows from combining the two — stopping, say, a flow that quietly copies SharePoint data to a personal Dropbox. Setting sensible DLP policies before staff start building is far easier than unwinding a mess later. Under the Privacy Act 1988 and the Australian Privacy Principles, you remain accountable for personal information your automations handle, so this is a compliance control, not just IT hygiene.
Service accounts and sprawl
Without guardrails, every department builds undocumented flows, and within a year nobody can tell you what automation is running across the business or what it touches. Govern it like any other production system: shared ownership for anything important, a naming convention, an inventory, and DLP policies set centrally. This is the same discipline behind our cybersecurity services work — who can build what, and where the data can flow.
When to use Power Automate versus hiring a developer
Power Automate is brilliant for connecting Microsoft 365 services and orchestrating standard business processes. It is not a replacement for proper software development, and pushing it past its comfort zone produces flows that are slow, hard to debug and impossible to hand over.
| Use Power Automate when | Hire a developer when |
|---|---|
| Connecting Microsoft 365 apps and standard services | Building complex logic with many branches and edge cases |
| Routing approvals, notifications and simple data moves | Processing high volumes where performance matters |
| Letting non-developers maintain the automation | Integrating systems with no connector via custom code |
| Quick wins that pay off in weeks | A genuine application with a user interface and a database |
The honest limits: flows can be slow on large data sets, error handling is clunky compared to real code, and a flow with fifty steps and nested conditions is a maintenance nightmare that one staff departure can orphan. If you are fighting the tool to force complex logic into it, that is the signal to step back. A well-scoped flow that saves an hour a day is a win; a sprawling flow only its author understands is a future incident. Where that line sits for your business is exactly what our virtual CIO conversations are built to answer.
Frequently asked questions
Is Power Automate free with Microsoft 365?
Largely, yes — most business and enterprise Microsoft 365 plans include seeded use rights to build and run cloud flows using standard Microsoft connectors such as Outlook, Teams, SharePoint and Forms. You pay extra only for premium connectors, or per-flow or per-user plans. Confirm current entitlements against your subscription, as Microsoft adjusts inclusions regularly.
What is the difference between a cloud flow and a desktop flow?
Cloud flows run on Microsoft’s infrastructure and talk to apps through connectors and APIs — reliable, and the right default. Desktop flows are robotic process automation (RPA): they run on a Windows machine and mimic a human clicking through software, which suits legacy systems with no API but is fragile and breaks when screens change.
Do I need a developer to build flows?
For standard automations — approvals, alerts, filing attachments, form-to-spreadsheet — no. A capable staff member or your MSP can build them in the designer. You need a developer when the logic gets genuinely complex, performance on large volumes matters, or you are integrating a system with no connector.
What happens to flows when a staff member leaves?
If a flow is owned by an individual’s account and you disable that account during offboarding, the flow stops. Business-critical flows should be owned by a shared service account or have co-owners so they survive staff changes. Reviewing what a leaver automated should be a standard offboarding step.
Where TechAssist fits
We are a Melbourne MSP, founded in 2014, with thirteen Australian-employed engineers — not an offshore queue. We help SMEs identify which manual tasks are worth automating, build the flows inside your existing licensing where possible, and set the DLP policies and ownership rules so automation does not become a security hole or a single point of failure when someone resigns. If you are paying staff to do work a flow could handle, or you have a tangle of flows nobody owns properly, get in touch and we will map the quick wins before you spend a dollar on premium licences you may not need.