Specialism
Microsoft Power Automate consultant
Power Automate is the layer most Microsoft 365 tenants already own and few use deliberately — a handful of personal flows, one mailbox trigger nobody documented, and a premium connector somebody switched on once. We design that layer properly, inside your own tenant, on licences you already hold wherever that is possible.
The work
What does a Power Automate engagement actually cover?
It starts with what already runs in the tenant and who owns it, then moves to the build: which flows belong in the cloud and which need a desktop robot, which connectors are standard and which are licensed, where the data should live, and how a failure is noticed by a person instead of sitting silently in run history.
Cloud flows and desktop flows. A cloud flow runs in Microsoft's service and starts from a trigger — a message arriving in a shared mailbox, a file landing in SharePoint, a row changing in Dataverse, a schedule, or a button in Teams. A desktop flow is robotic process automation, or RPA: software driving an application's interface the way a person would, which is how you automate a line-of-business system that never got an API. Cloud flows are the default; a desktop flow is what you reach for when there is genuinely no other way in, and it carries a maintenance cost because a screen change breaks it.
Connectors, standard and premium. A connector is the pre-built adapter between a flow and a system. The standard set covers the Microsoft 365 surface most teams start with — Outlook, Teams, SharePoint, OneDrive, Excel. The moment a process touches a database, an HTTP call, or many third-party business systems, you are in premium territory and licensing enters the design conversation. Where no connector exists we build a custom one against the vendor's published API rather than pasting credentials into an HTTP action.
Dataverse, or something simpler. Dataverse is the Power Platform's own database, with tables, relationships and a permission model that follows the user. It is the right home for structured business records that several apps and flows share. It is also frequently proposed where a SharePoint list would have done, and we will say so — the cheapest architecture that survives the next two years is the one worth building.
Environments, solutions and ownership. The failure we are called in to fix most often is not a broken flow, it is a flow built in the default environment, owned by a personal account, holding a connection to a mailbox belonging to someone who has since left. The fix is boring: environments that separate a build from live, solutions as the unit you export between them, connection references and environment variables so nothing points at a developer's own account, and an owner who is a role rather than a person.
Failure handling that a person actually sees. Every flow gets an explicit answer to what happens when a call fails: which actions run after a failure, what is retried and how many times, what gets parked for a human, and where the alert lands. Left at the default, a repeatedly failing flow can be suspended automatically and the notice goes to whoever owns it — which is exactly why the ownership work above is not administrative tidiness.
| Job | Where it belongs | What to watch |
|---|---|---|
| React to mail, files or Teams messages | Cloud flow on standard connectors | Trigger from a shared mailbox or site, never a personal account |
| Route a request for sign-off | Cloud flow using the Approvals action | What happens when the named approver is away or has left |
| Drive a legacy application with no API | Desktop flow (RPA), attended or unattended | Screen changes break it, and unattended running is licensed separately |
| Hold structured records several flows share | Dataverse tables | Whether a SharePoint list is honestly enough for now |
| Call a system with no ready connector | Custom connector, or an HTTP action | Premium licensing, and secrets kept out of the flow body |
| Move a build from testing to live | Solution export into a separate environment | Connection references and environment variables, so nothing points at a person |
| Orchestrate many non-Microsoft SaaS tools | An automation platform outside the tenant | Where run history, retries and the error route now live |
Licensing and platform limits are a design input, not an afterthought. What a flow may call, how often it may call it, and whether that needs a premium plan all shape the architecture before a single action is placed. We design against the vendor's own published material — the Microsoft Power Automate documentation (opens in new window) and the published Power Platform request limits and allocations (opens in new window) — so your IT team is reviewing an architecture Microsoft describes, not something only we understand. We do not quote licence costs on this page; your tenant and your Microsoft agreement decide those, and we would rather check them with you than guess.
Where it fits
When should a process leave the tenant for another platform?
When the centre of gravity moves outside Microsoft 365. A process whose data, identity and documents already live in Outlook, SharePoint, Teams and Dataverse belongs in a flow, close to its permission model. A process that spans a dozen third-party SaaS tools, needs heavy branching and retry logic, or would push you into premium licensing for one connector is usually cheaper and clearer somewhere else.
That decision is a platform question, not a Microsoft question. Our workflow automation page describes how we scope, build and hand over a process regardless of what it runs on, and it is the right starting point if you have not settled on a platform at all. If the answer comes back as a dedicated orchestrator, n8n consulting covers what a build there involves and what self-hosting commits you to, and Make.com consulting is the equivalent for scenario work. Plenty of accounts end up with both: flows for everything native to the tenant, an orchestrator for everything that crosses the boundary. If you are a small business weighing those two options against each other before committing, our comparison of n8n vs Power Automate for small business sets out the licensing shape, self-hosting and governance differences and ends with a decision. If you have already decided to leave, our Power Automate to n8n migration service covers moving existing flows across without losing what they do. How an engagement is scoped, staged and handed over is set out on how it works.
There is a second boundary inside Microsoft's own stack, and it is the one most often blurred. Power Automate runs trigger-based cloud flows that nobody talks to; Copilot Studio builds conversational agents a person converses with, on its own tenant licensing and its own sharing rules. This page does not sell agent building — if what you actually want is something staff or customers ask questions of, our Microsoft Copilot Studio consulting page covers that side. The two are commonly deployed together, with an agent calling a flow when it needs work done, which is exactly why the line between them is worth drawing before the build rather than after. Our comparison of Copilot Studio vs Power Automate draws it job by job.
Inheriting flows somebody else built
A second opinion on an existing estate is a common request, and the review is the same each time: what is actually running, in which environment, under whose account, on which connections, and what breaks when that person's licence is reclaimed. Then which flows still earn their place, which duplicate each other, and which are quietly failing without anyone reading the run history. You get a plain answer on what is worth repairing and what is cheaper to rebuild — including the answer nobody sells you, which is that the flows are fine and the real problem is the form or the mailbox feeding them. If any of those flows touch patient records, our guide to whether Power Automate is HIPAA compliant shows where Microsoft's agreement stops and which connectors fall outside it.
Questions
Practical questions about flows, connectors and licensing
Do we already have Power Automate, or is it a separate licence?
Most Microsoft 365 business subscriptions already include flows built on standard connectors, which is why so many tenants have a few running without anyone deciding to buy anything. Premium connectors, Dataverse and unattended desktop flows sit outside that and need paid plans. We check your tenant before designing anything, so the licence question is answered first rather than discovered late.
Should this run in Power Automate or in a dedicated automation platform?
Power Automate when the work lives inside Microsoft 365: Outlook, Teams, SharePoint, Excel, Dataverse and the identity model around them. A dedicated orchestrator when the process spans many non-Microsoft tools, needs heavy branching and retries, or would push you into premium licensing for a single connector. We will tell you which side a given process falls on.
Are you a Microsoft partner or a certified Power Platform consultant?
No, and we will not claim a badge we do not hold. We are an independent consultancy that builds on the documented Power Platform surface, in your tenant, on your licences. If a partner badge is part of your procurement requirement, say so on the first call and we will tell you straight away that we do not meet it.
Who owns the flows once the work is finished?
You do. Everything is built in your environments, under owners you nominate rather than a personal account that leaves with an employee, and packaged as solutions you can export. You get the documentation for what each flow does, what it connects to and how it fails, so your team or any other consultancy can pick it up.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.