The approval form turns up after the app is live

Most low-code governance I have reviewed fails at the same point. The intake form asks for a business case, a data classification and a sponsor, and it gets completed months after the app went live because someone in the platform team finally noticed it. I watched this happen with a shift-handover app in a distribution centre. By the time the form reached a reviewer, three hundred people opened it every morning, and the honest answer to the approval question was that nobody was going to switch it off.

That form shaped nothing. It did teach every other maker that review means delay, which is why most default environments hold hundreds of canvas apps on personal connections no admin has ever opened. My answer is to move the review earlier and make it much smaller. A fifteen-minute conversation before the first screen exists does more than any form completed afterwards, and it is the pattern behind most of what we publish on low-code governance.

Three questions before the first screen

When a maker tells me what they want to build in Power Apps, I ask the same three things. What work is changing, meaning which task a person does today that will be different tomorrow. Who owns the data the app reads and writes. And what happens when a request fails.

The second question does most of the work. A maker once told me the app only used a SharePoint list they had set up themselves. It also patched the Account table in Dataverse, because a lookup was easier than typing customer names by hand. The CRM team found out when duplicate accounts turned up in a pipeline report, and that conversation was far longer than the one we could have had in the first week.

The third question is the one people skip. Every flow fails eventually, so the question is who sees it. I have seen the failure notification go to the mailbox of a maker who had moved teams, and the person who finally noticed was a payroll clerk wondering why overtime claims had stopped arriving. If the maker cannot name who sees the failure, that is the first design gap, and it is cheaper to find now than in a helpdesk ticket.

  • What work is changing, and for whom. Name the task, the team, and roughly how many people will use the app in the first month.
  • Who owns each table or list the app touches. Name the person who would be asked if a value in it looked wrong.
  • What happens when a request fails. Name who sees the failure and what they do about it before anyone writes retry logic.
  • Who else reads the result. A report, a downstream flow, or another team that depends on the output should be named now.
  • How the maker would know the app is wrong. A count that should match, a record that should exist, or a person who will complain.

Write the answers where the solution lives

None of this needs a form. It needs ten minutes and someone who writes the answers where a future owner can find them. I have seen the answers put in a Teams channel that was archived when the project closed, while the app ran for three more years. In Dataverse the obvious place is the solution itself. Put the answers in the solution description, or in a small governance table in the same environment with one row per solution, a named owner, a data owner and a review date.

Three or four sentences that record the original boundary are enough. When the app that tracked equipment calibration for one lab quietly becomes the app for every lab on the site, whoever inherits it needs to know the original design assumed forty users and one data owner. That is the moment the app needs its own environment and a release path, and the record tells you the moment has arrived. Our guide on how many Power Platform environments you actually need picks up from there.

The last question on the checklist earns its place. A maker who can say how they would detect a wrong answer has thought about the app harder than many project teams think about a large integration. Write the detection method down too. It becomes the first line of the runbook.

Sort apps by what breaks when they are wrong

One review process for everything is what makes intake a delay. A personal app that reads the maker's own mailbox does not need the attention owed to an app that writes to the customer table and triggers a Power Automate flow into the order system.

I use three lanes. Personal tools stay in the default environment, labelled that way, with no review beyond the DLP policy already in place. Team tools get the questions above and a named owner, and they stay where they are until a second team asks to use them. Anything that writes shared data, runs unattended, or feeds another system moves to its own environment and goes through a release checklist for shared solutions before more makers touch it. The platform team only spends real time on the third lane.

The objection I hear most is that makers will put their own work in the wrong lane to avoid review. They rarely do, because the questions make the lane obvious. An app that writes to a shared table has a data owner other than the maker, and that answer alone places it in the third lane. When someone does get it wrong, the release conversation catches it, which beats an intake form nobody read.

Design the support call before anyone makes it

The other half of lightweight governance is the day the app breaks. I sat with a helpdesk team that received a ticket about an app none of them had heard of, built by someone who left in the spring, running on a connection tied to a disabled account. The flow had failed silently for three weeks. The failure emails went to a mailbox that no longer existed.

Three things prevent that call. A named owner and a named second, both current employees, recorded where the helpdesk can find them. A one-page runbook that says what the app does, which data it touches, and how to switch it off safely. And a route for a user to report a problem that reaches a person, whether that is a support queue, a channel, or a shared mailbox with a rota. For anything in the third lane, connections through a service account rather than the maker's own credentials belong on the same list. Our piece on where automation ownership breaks down covers what happens without a recovery owner, and most of those failures start with a missing name.

None of this is heavy. The owner, the second and the report route take five minutes. The runbook takes half an hour, and the maker already knows most of it. Both belong in the same governance table as the intake answers, which is how a small center of excellence knows which apps are supported without becoming responsible for all of them.

What I say when someone proposes an approval board

Every few months someone proposes a proper board. A committee, a form with twenty fields, a monthly meeting. The outcome is predictable. Makers build in the default environment and wait until the app is too popular to refuse. What I say in that meeting is that the board will approve things it cannot stop and slow things it does not understand, and that the tenant already contains a governance record nobody has read.

Then I ask for something smaller. Take the ten most used apps in the default environment this week. Find the maker of each one and ask the questions. Record the answers on the solution, name an owner and a second, and sort each app into a lane. You will find at least one app that belongs in the third lane and has never been reviewed. Bring that app to the next meeting instead of a policy slide.