Every MSP I talk to has the same Power Automate problem.
Not a tech problem. A consistency problem.
Client A has a leave-request flow built by some intern in 2022. Client B has an onboarding flow that emails three people, one of whom left last year. Client C runs approvals through someone’s personal Outlook because it was “quicker that way”.
That’s not automation. That’s tribal knowledge held together by hope.
The fix isn’t more flows. The fix is three flows, built once, exported, and dropped into every client tenant you touch.
What is a Power Automate solution, really?
A flow on its own is a personal toy. It lives in someone’s default environment, it’s owned by one person, and the day they leave the tenant the flow dies with them.
A solution is that same flow, packaged with connection references and environment variables, exported as a file, and imported into any other tenant. Same flow. Different SharePoint site, different approvers, different mailbox — wired up at import time, not hardcoded.
That’s the move. Stop building per-client. Start building once and deploying everywhere.
If you’re charging your clients for automation as a service, this is what productisation actually looks like.
The three worth standardising
There are hundreds of templates in the Power Automate gallery. Most MSPs don’t need hundreds. They need three:
- Approvals — anything that needs a yes/no with an audit trail
- Joiner (onboarding) — new staff member, day one
- Leaver (offboarding) — staff member out, access gone, evidence kept
Build those three properly as a managed solution and you’ve covered eighty percent of the automation requests you’ll get from an SMB client this year.
Step-by-Step: stand up the Approvals flow first
Open Power Automate inside a dedicated solution
Sign in to Power Automate, pick Solutions on the left, and create a new one. Give it a publisher name like YourMSP_Automation. Don’t skip this. Flows created outside a solution can’t be exported cleanly later.
Pick the right approval type
Open the Start and wait for an approval action and look at the dropdown. There are four real options — Approve/Reject – Everyone must approve, Approve/Reject – First to respond, Custom Responses – Wait for all responses, Custom Responses – Wait for one response — plus sequential. Most SMB approvals are First to respond. Document sign-offs are usually Everyone must approve. Pick deliberately. The full approvals reference is on Microsoft Learn.
Use environment variables for the approvers, not hardcoded emails
This is the bit MSPs skip and then regret. Don’t type finance@clientco.com into the Assigned To box. Create an environment variable called ApproverEmail, reference it in the action, and set the value at import time.
Here’s what the assignment looks like in the action:
@{parameters('ApproverEmail (yourmsp_approveremail)')}
Notice what’s missing? A client name. That’s the point. Same flow, twelve tenants, twelve different approver emails — none of them baked into the export.
Export it as a managed solution
Solutions > your solution > Export > Managed. You ship managed solutions to client tenants and keep the unmanaged copy in your build tenant. Microsoft’s import guide walks through what the receiving tenant sees — connection references prompt for new accounts, environment variables prompt for values, and your flow turns itself on when it lands.
Joiner and Leaver follow the same shape
For Joiner the trigger is usually a new Microsoft Lists item or a Forms submission. The flow creates the Entra user, assigns licences, drops them into groups, posts a welcome card to a Teams channel, and sends the manager an approval to confirm everything looks right before the password lands in the helpdesk mailbox.
For Leaver the trigger is the same list, different status. The flow disables sign-in, revokes sessions, converts the mailbox to shared, transfers OneDrive ownership to the manager, and writes a row to a SharePoint list that becomes your audit trail when the cyber insurance auditor asks “what was your offboarding process on the 14th of March?”.
Both flows reuse the same three environment variables — HelpdeskMailbox, ManagerApprovalGroup, OffboardingEvidenceList. Build once. Import twelve times. Done.
One more thing: lock the connectors down before you ship
Before you push any of this into a client tenant, set a Data Loss Prevention policy in the Power Platform admin centre. Put Office 365, Approvals, SharePoint, and Teams connectors in the Business group. Put Twitter, Dropbox, Gmail, and the rest in Non-Business or Blocked. Microsoft’s DLP guidance spells out why this matters: without it, any maker in the tenant can build a flow that pipes mailbox data into a personal Dropbox.
Before: “Can you build us a leave-request flow?”
After: “We’ll deploy our standard approvals solution to your tenant on Friday.”
That’s the shift. From bespoke build to productised deployment. From “this might take a few days” to “this is a forty-minute import”.
Why this actually changes behaviour
If you’re an MSP and you’ve built the same flow three times for three clients, you’re not running an MSP. You’re running a freelance bench with a logo.
The three-flow library — approvals, joiner, leaver — is the smallest automation product that pays back. It compresses delivery time. It standardises what “good” looks like across every client you touch. And when a client says “we’d like our offboarding to leave evidence for our cyber insurer”, you don’t quote a project. You import a solution.
Here’s the real win. Once these three are running cleanly, the conversation with the client changes. They stop asking if you can automate something. They start asking what else you’ve already got in the library.
That’s where the margin is.
Build the flow once. Sell the deployment every time.
CIAOPS 