Power Automate Consulting in Australia: The Licence Is the Architecture

Partly, and the boundary is where most budget surprises live. Microsoft 365 business and enterprise plans include rights to use Power Automate with standard connectors, broadly to automate work within the Microsoft services you already pay for. What is not included is the premium set: SQL Server, Dataverse, custom connectors, the plain HTTP action, the on-premises data gateway and a long list of third party business systems. Those require premium licensing: Power Automate Premium for a named user, Power Automate Process for a specific flow, or the pay-as-you-go meter if you would rather not buy licences up front. The practical rule is that if your automation only moves things around inside Microsoft 365, your existing licences probably cover it. The moment it touches a line of business system outside that boundary, price the premium licence before you design anything.

It depends entirely on the shape of the automation rather than on the size of your organisation. The per-user licence is now called Power Automate Premium and it gives one named person unlimited premium flows, so it suits a scenario where many staff each need their own automations, for example a team of analysts each running premium connectors. The per-flow licence is now called Power Automate Process and it covers one specific flow no matter how many people it serves, so it suits a single central automation such as invoice processing or a customer intake pipeline used by the whole business. Two conditions on Process are worth knowing before you design: the flow has to live inside a solution, and each licence carries a ceiling of 250,000 actions a day, with a flow group sharing one licence across up to twenty-five related flows. There is also a third option people forget, Microsoft’s pay-as-you-go meter, which gives you premium capability with no licence bought up front and suits low or unpredictable volume. If a quote in front of you says Per-user plan or Per-flow plan, those are Microsoft’s legacy names and it says not to renew them. The maths tips between the shapes at surprisingly small numbers, and the answer changes how you architect the solution, because Process rewards consolidating into fewer well governed flows. We model all three against your actual list of processes before recommending anything.

Power Platform environments can be created in the Australian region, and for organisations with residency obligations that is a meaningful advantage over automation tools hosted elsewhere. Two practical cautions. First, the environment region is set when the environment is created and is effectively permanent. Microsoft does offer a geo migration, but it is limited and generally not available, it needs an add-on SKU, it takes at least ten days, it changes your environment URL and loses backups, the default environment cannot be migrated at all, and migrations into or out of Oceania are specifically restricted. Worth knowing too that an Australian environment generally requires an Australian tenant. Decide the region before anyone builds rather than discovering it during a security review. Second, residency of the automation platform does not automatically mean residency of everything it touches: a flow calling a third party service still sends data to wherever that service runs. Map the data flow end to end, not just the platform, and document it, because that document is what a client or auditor will ask for.

A flow runs on the connections of whoever created it, so what we find in practice is that flows stop when a departing employee’s account is disabled. Worse, the failure notice goes to that same mailbox, so nobody finds out until the business process visibly breaks, which can be weeks later for a monthly process. The fixes are straightforward and almost universally skipped: own business critical flows with a service account or solution connection references rather than an individual, always add co-owners, route failure alerts to a monitored shared channel, and add a step to your offboarding checklist that checks for flows owned by the departing person. We treat this as a standard part of delivery rather than a nice to have.

Not better, differently suited, and we work across all of them. Power Automate wins clearly when your organisation is committed to Microsoft 365, when identity and data policy governance genuinely matter, and when the automation is mostly about Teams, Outlook, SharePoint and the systems your IT team already controls. It loses when you need to call arbitrary APIs cheaply, when your volume involves heavy per-record loops that suit execution-based pricing, or when your business does not run on Microsoft at all, in which case you are paying the complexity of the Power Platform without collecting its main benefit. The honest test is whether the governance advantage applies to you. If it does not, look elsewhere.

Only when the system you need to automate genuinely has no supported interface. Desktop automation works by driving the application’s screens the way a person would, which makes it the right answer for old on-premises software that will never get an API. It is also the most fragile automation you can build: a vendor update that moves a control breaks it, running it unattended requires a Power Automate Process licence and a registered machine that stays powered on and reachable, and storing the credentials it needs deserves proper thought. Always check for an API, a database view or a supported file export first. Screen automation should be a last resort you chose knowingly, with a plan for what happens when the vendor next changes their interface.

Start with an inventory rather than a rebuild. Pull a report of the flows in your tenant, who owns them, which connectors they use and when they last ran, then sort them into three groups: business critical, personal productivity, and abandoned. The abandoned ones get turned off. The personal ones get left alone but constrained by a sensible tenant data policy. The business critical ones get moved into a proper environment, packaged as solutions, re-owned to service accounts and given real alerting. That sequence gives you the risk reduction quickly and the rebuild cost only where it is justified, which is a far easier case to take to a board than a proposal to redo everything.