Short answer: we don’t rely on just sharing apps/flows and hoping people hand them over before they leave. We try to design things so that no single individual is a “single point of failure”.
Here’s how we handle it in our DEV environment and downstream:
1. Controlled access to DEV
Access to our DEV environment is managed via a security group, so we always know who is developing there and can manage access centrally.
This follows Microsoft’s general guidance to use multiple environments and control access as part of your ALM/environment strategy.
2. Everything must be in a Solution (with naming convention)
We have a simple rule: no “loose” apps or flows in DEV.
Every asset (apps, flows, tables, etc.) has to live inside a Solution. We enforce a solution naming convention that tells us:
- What the solution is for
- Which business unit / group company it belongs to
- Whether it’s internal, external, POC, etc.
This means there are no stray apps/flows floating around that nobody can trace back to an owner or team.
3. First deployment: manual sanity check, then pipelines
When a new Solution is ready for the first time:
We usually do a manual export/import from DEV>TEST>PROD for the initial release, just to validate:
- Connections
- Environment variables
- Any dependencies
Once that’s stable, we switch to Power Platform pipelines so that our more mature citizen devs can deploy updates themselves without an admin doing every import.
This aligns with Microsoft’s ALM guidance around using multiple environments and automating deployments once your basic process is solid.
4. “Non-human” account for promotion & ownership
This is the key part that answers your question about people leaving.
For DEV>TEST>PROD we do not deploy as my personal account (e.g. AndyCutler@mycompany.com).
Instead, we use what I call a “non-human” account, for example: 12345678@mycompany.com
Characteristics:
- It’s a dedicated service account in Entra ID / M365
- It’s aliased to me (and a backup person), so we handle login, MFA, etc.
- It owns the solutions and connections in TEST/PROD, rather than an individual user
- If I leave the company, and my personal account is disabled, all the PROD solutions keep working because the service account remains under IT control
This is very much in line with Microsoft’s concept of system / application users and non-interactive accounts used for back-end or service scenarios.
5. How we handle maintenance & handover in practice
So, to your question:
“Do you just share all apps and flows respectively so that somebody leaving can hand it over or is there a better approach?”
Our approach is:
In DEV:
Multiple makers can be co-owners of apps/flows inside the same Solution.
The Solution itself lives in a controlled, shared environment — not in a personal environment.
In TEST/PROD:
The service account is the owner of the Solution and key connections.
Makers don’t need to be owners in PROD to maintain the app; they update in DEV, and the pipeline/service account pushes the managed Solution downstream.
If a developer leaves:
We reassign any remaining DEV-side assets (if needed) and/or remove them from the security group.
No PROD outages, because nothing critical is owned by their personal account.
So we’re not relying on “please share everything before you leave”; the ownership is already abstracted away from individual users.
6. Why this works well
Reduces risk of orphaned apps/flows when someone leaves
Keeps PROD ownership under central IT / service account control
Lets citizen devs still work fairly independently in DEV, but within a governed ALM model
