When the maker of a Power App leaves, the technical account is only part of the problem. The organization may also lose the person who understands the business rules, connections and decisions on which the application depends.
The risk is easy to miss while everything works. A well designed app may run for months with little attention. Users see a dependable service. IT sees no incident. The original maker quietly remains the only person who knows how the pieces fit together.
A named owner may not be an effective owner
Adding a second owner is sensible, but it does not transfer knowledge by itself. The additional owner may be a manager, a colleague or an administrator who has never opened the application in edit mode.
Business ownership and technical ownership answer different questions. The business owner decides whether the application is still needed, who should use it and how important the process is. The technical owner understands how the app works, which connections it uses and how to restore service when something fails.
An important application needs both forms of accountability. One person may hold both roles, but the responsibilities should still be clear.
Connections often reveal the dependency
Power Apps rarely operate alone. They may call Power Automate flows, read a SharePoint list, use Dataverse or depend on several connectors. Some of those connections may be tied to an individual account.
When that account is disabled, the visible app can remain available while an important process behind it begins to fail. The first sign may be a missed approval, an incomplete record or a queue that quietly stops moving.
Ownership reviews therefore need to cover the application and its dependencies. Reviewing the app record alone gives only part of the picture.
Find ownership gaps before the leaving date
The best time to resolve an ownership problem is while the maker is still available. A regular comparison between Power Platform ownership and Microsoft Entra ID can reveal disabled accounts, departed staff and resources without a valid accountable owner.
The review should then establish how widely the resource is used and what business process it supports. An abandoned experiment can be retired. An active team app may need a new owner. A business critical application needs a deliberate handover and a support decision.
What a useful handover contains
A handover does not need to become a large documentation exercise. It should explain the purpose of the application, the people who depend on it and the effect of an outage. It should identify the app, its flows, connectors, data sources and environments. It should also record who can make changes and who accepts responsibility for the business process.
For a small departmental app, a concise record and a capable second owner may be enough. A service used across several business units may need version control, testing, release management and a formal route into support.
The right level of control depends on the consequence of failure, not on whether the application began as citizen development.
Ownership is a continuing process
A valid owner today does not guarantee a valid owner next year. Staff move, teams reorganize and applications outlive the projects that created them. Ownership needs a review cycle.
MOCA365 Power Platform Governance identifies ownership problems across apps and flows and supports a governed response. Administrators can see resources with invalid ownership, assess their importance and reassign them in the Power Platform admin center before a departure becomes an outage.
See how MOCA365 governs Power Platform ownership and lifecycle across the estate.