You should own the Power Platform solutions a consultant builds for you, but whether you actually do comes down to three operational checks: whose tenant it lives in, who holds the owner role, and whose accounts the connections run under. Ownership sounds like a legal question. Contracts matter, but these three checks decide whether you can keep running and changing the system without the supplier, and they are worth making before you sign anything.
1. Whose tenant does it live in?
Everything built for you should sit in your Microsoft tenant, on your licences. If any part runs in your supplier's environment, you are renting your own process, and leaving becomes an extraction project.
This is not always obvious. The app might open from your Teams, but a flow behind it could be running in the supplier's tenant, calling into yours through a connection. Or an agent might be built in their environment "for development" and never moved. Signs to look for:
- A connection or app registration created in a tenant that is not yours
- Data being copied to a database or storage account you do not have access to
- Licences for the solution billed through the supplier rather than to you
- Anything you can only see by logging into their portal
Ask directly: after go-live, does anything we depend on run outside our tenant?
2. Who holds the owner role?
Check the actual owner on the apps, flows and solutions. It is very common for these to be owned by the consultant's account — often not deliberately, but because that is who created them.
In the Power Platform, the person who creates a flow or app is its owner by default. If the consultant built everything under a guest account in your tenant, or under a named account you created for them, those items are tied to that account. When the account is disabled at the end of the engagement, flows owned by it can stop running, and nobody on your side may have the rights to fix them.
Your team should be co-owners from day one, not added at the end. When the engagement finishes, your team should be the only owners.
How to check
You do not need to be a developer to look. In each case you are checking the "Owner" or "Co-owners" field:
- Flows: in Power Automate, open the flow's details page and look at the owners panel.
- Apps: in Power Apps, open the app's details and check the owner and the "Share" list for co-owners.
- Solutions: in the environment's Solutions area, check that the apps and flows sit inside a named solution rather than loose in the environment.
- Environment: in the Power Platform admin centre, check who holds the environment admin role.
If you see a name you do not recognise, or a personal account of someone who no longer works with you, that is the thing to fix.
3. Are the connections in service accounts?
If flows authenticate as an individual — theirs or yours — they break when that person leaves. Connections should use service accounts your organisation controls, with documented credentials and expiry dates.
A service account here means a Microsoft 365 account that belongs to the organisation, not a person, such as one used only to run automations, with its password and multi-factor setup held by IT. The same logic applies to app registrations used for API connections: they should be registered in your tenant, with the secrets stored where your team can reach them and their expiry dates written down. The handover documentation checklist has a simple register for this.
The three checks at a glance
| Check | What good looks like | Warning sign | Fix |
|---|---|---|---|
| Tenant | Every app, flow, agent and data store in your tenant | Anything running or stored in the supplier's environment | Move it into your tenant before go-live |
| Owner role | Your staff are owners; supplier accounts removed at the end | Supplier or ex-staff accounts as sole owner | Add your owners, then remove theirs |
| Connections | Service accounts and app registrations you control | Connections signed in as a named person | Re-create connections under a service account |
The question that reveals the answer
"If we ended the engagement tomorrow, what stops working?"
The honest answer should be "nothing stops; you just stop getting changes made". Anything else means you have a dependency you were not told about.
It is a fair question to ask in a sales conversation, and a good partner will answer it without hesitation. If the answer involves a licence you would need to buy from them, a component only they can maintain, or a hosting arrangement, ask for that in writing and price it into the decision.
What happens at the end of an engagement
Ownership is easiest to get right if it is planned in, not cleaned up at the end. A sensible sequence looks like this:
- Before signingConfirm in writing: your tenant, your licences, your ownership
- Kick-offYour owners and a service account set up; supplier works as co-owner
- During buildApps and flows created inside a named solution; connections under the service account
- Go-liveOwner check done together; credentials and expiry dates documented
- Engagement endSupplier accounts removed as owners; solution exported and stored in your tenant
The export step is cheap insurance. An exported solution file is a copy of the build you can re-import into another environment if something goes wrong, and it should be stored somewhere you control, such as a document library on your IT or systems SharePoint site.
What to put in writing
The operational checks are what keep the system running, but the contract should back them up. You do not need a long clause. A few plain sentences in the statement of work cover most of it:
- Location: all solutions, data and connections will be built and stored in the client's Microsoft tenant, on the client's licences.
- Intellectual property: the client owns the solutions built for them, including the exported solution files and documentation.
- Accounts: supplier accounts will be removed as owners at the end of the engagement, and connections will run under client-controlled service accounts.
- Handover: the deliverables include an architecture note, a connection register and exported solution files.
If a supplier uses its own reusable components or templates, it is reasonable for them to keep the rights to those, as long as you have a licence to keep using them in your build without ongoing fees. Ask that question explicitly; it is the one most likely to surface a hidden dependency. If anything in the contract is unclear, get your own legal advice. The point here is simply that the written terms and the tenant should say the same thing.
Ownership is not the same as being able to change it
Owning the build means it keeps running and you have the rights to change it. Being able to change it safely also needs documentation, a named person on your side and sensible design, such as approvers and thresholds held in lists rather than written into the flow logic. That is the difference between "we own it" and "we can live with it". Both matter.
It is also fine to keep a supplier on for changes and support after go-live. A retainer is a choice you make because it is useful, not a requirement because you cannot do without it. Ours start from $3,000/month, and leaving one should not break anything.
What good looks like
- Your tenant, your licences, your data
- Your staff as solution owners, with supplier accounts removed at the end
- Service accounts you control, documented, with expiry dates
- Apps and flows inside a named solution, not loose in the environment
- Source solutions exported and stored somewhere you can reach
- A written answer to "if we ended tomorrow, what stops working?"
None of this is unreasonable to ask for, and a good partner will have done it by default. Everything we build is in the client's own tenant and owned by them; the solutions page shows the kinds of builds this applies to.
What to do next
If you already have Power Platform builds from a previous supplier, run the owner check this week: list every flow and app, and note who owns it and what account each connection runs under. Anything owned by an individual, or a supplier account, goes on a short fix list. If you would rather have someone do that review with you, the free diagnostic audit includes it.
Want the version for your business?
Work out what manual processes are costing you — three minutes, no contact details needed.
Work out the cost