Who owns your business app when its maker leaves?

Imagine the employee who built your purchase-approval app gives notice. The app is useful. People rely on it. Their replacement can open it, so the handover looks straightforward.

Then someone asks where the supplier file lives, whose account sends the approval emails, and who can change the spending threshold. The answers lead back to the person who is leaving.

That is an illustrative scenario, but the dependency is real enough to have its own Microsoft documentation. A business app can be widely used while the ability to maintain it remains concentrated in one account. For an owner commissioning software, that is worth addressing while the maker is still available.

A useful application needs a handover that survives a change of staff. Illustrative photo by Alex Tyson / Unsplash.

Faster app building makes ownership easier to overlook

Microsoft's September 17 Power Platform update includes six additional canvas-app screen templates and new quick-start cards for Power Automate. They make it easier to begin useful work. An operations team with a recurring problem should be able to build a sensible tool without turning every request into a major software project.

The purchase decision still needs to include what happens after launch. Faster authoring does not, by itself, tell you who receives failure alerts, can update a connection, or has permission to publish a correction. Those responsibilities need an explicit home.

This applies to a custom web application too. A repository in a contractor's personal account and a deployment that only works from their laptop can create much the same handover problem.

The owner field only tells part of the story

There are several distinct questions hiding inside “we own the app.” Who decides how the business process should work? Who can edit and release the software? Which accounts can access its data? Who will respond when it fails?

Microsoft's canvas-app sharing guidance makes an important distinction: an app also depends on permissions for its data sources and, potentially, resources such as flows, gateways and connections. Giving somebody access to the screen does not establish access to everything behind it.

For the hypothetical purchase app, the supplier list, approval flow, outgoing mailbox and published app might each have different permissions. A replacement could successfully submit a request while lacking the access needed to repair the email step. A successful login would leave that gap undiscovered.

Start with a small map of the workflow. Follow a request from entry to completion and record the systems it touches. Beside each system, write the responsible person or team, the account it uses, and how an authorized replacement obtains access. Record credential locations in your approved password manager, not passwords in a handover document.

A co-owner is useful, but connections still matter

Microsoft describes orphaned flows as flows without a valid owner and warns that they can fail when their connections depend on the departed user's account. It provides administrative recovery routes. That is a reason to plan the transfer; it is not evidence that every departure immediately stops every app.

The transfer method also depends on what was built. Microsoft's cloud-flow ownership guidance allows an ownership change for a solution-aware flow. A non-solution flow cannot have its owner changed in place; the documented options depend on whether the environment has Dataverse and can involve moving it into a solution or creating a replacement flow.

You do not need to become a Power Platform administrator to buy a small internal tool. You do need the supplier or internal team to identify the relevant transfer path. Ask them to check the replacement owner's licensing and connection permissions as part of that work, rather than treating a changed name in the owner field as the finish.

Keeping a former employee's login alive indefinitely is a poor substitute for a supported ownership arrangement. Choose an appropriate organizational identity where the platform supports it, with the necessary permissions and licensing. Avoid making a shared password the business-continuity plan.

Put a usable handover in the scope

A handover does not have to be a large manual. For a modest application, a short, maintained record can answer the questions that matter:

• Purpose and business owner: what the app does, who approves changes, and which parts of the process remain manual.
• Location and access: the company-controlled environment or repository, deployment destination, data sources, and who administers each.
• Accounts and renewals: the connections, subscriptions and credentials it depends on, who maintains them, and where renewal or failure notices arrive.
• Change and recovery: how a small correction reaches production, how the previous working version can be recovered, and which data needs separate protection.
• Support responsibility: who handles an incident, what the maintenance agreement covers, and how the next maintainer receives the current documentation.

Agree on this before the build starts. If you are inheriting an existing app, collect the same information before commissioning extra features. Missing ownership details are easier to resolve while the original maker can explain the choices.

Let the next maintainer do one ordinary job

Have the replacement make a harmless change in a test environment using their own authorized account. They should be able to locate the project, explain the relevant connections, make the change and follow the documented release process. The original maker can watch and answer questions; each missing step becomes a correction to the handover.

Keep the exercise proportionate. A simple approval app does not need the operating model of a national payments platform. It does need a realistic way for someone else to maintain it. Plan account changes with the administrator and the normal offboarding process; do not experiment by disabling a real employee's access in production.

If that exercise exposes a few missing permissions or unclear notes, fix those gaps. It does not automatically justify rebuilding the application. Rosecraft's technical assessment work can help establish what an inherited system needs before you commit to further application development.

The handover is finished when the next responsible person can do the work. Make room for that in the project.