Both extremes come from the same missing decision

Most tenants I review sit at one of two extremes. The first is the default environment holding everything: a few hundred canvas apps, well over a thousand flows, and a handful of Dataverse tables that a finance process quietly depends on, with no way to tell which of those matter. The second is the tenant that got burned by the first and now runs sixty environments, one per app, half of them with no owner anyone can name and a capacity bill nobody planned for.

Neither is an operating model. Both come from skipping the same decision, which is saying what an environment is for and who answers for it. The number of environments falls out of that decision. Start from the number instead and you get the wrong answer in either direction.

What follows is the rule I use when a platform owner asks me how many they need. It fits on a whiteboard, and it has held up with thirty makers and with three thousand.

Blast radius decides which solutions get their own pipeline

The question for each solution is what breaks, and for whom, when it goes wrong. I ask four things. Does it write to data another team reads? Does a business process stop when it stops, such as a purchase order that cannot be approved or a customer case that cannot be created? Do people outside the company touch it, through Power Pages or a shared link? And will anyone be expected to fix it at eleven at night?

A yes to any of those pushes the solution toward its own dev, test, and production environments with a pipeline between them. A no to all four means it can live in a shared team environment, promoted by hand or never promoted at all.

The example I use in the meeting is an expense approval flow. It started as one maker's convenience for a single department. Then a second department asked for it. Then finance pointed a Power BI report at the Dataverse table it fills. At that moment its blast radius changed and the environment it lived in stayed the same. That is the point to move it, and most teams miss the moment because nobody was watching for it. The Dataverse hub has more on the table ownership side of that problem.

Compare it with the team vacation tracker. It reads a SharePoint list, nobody outside the team sees it, and if it breaks on a Friday someone fixes it on Monday. Giving that its own three environments and a pipeline is how you get to sixty.

The default environment is a personal workspace, so name it that way

Every licensed user can create in the default environment and you cannot stop that. What you can do is decide what it means. I ask platform owners to rename it to something honest, such as Personal Productivity, and to put a DLP policy on it that keeps premium connectors and business systems out. The rename does real work. When a maker sees Personal Productivity in the environment picker, they understand that what they build there is theirs and that nobody will support it. When the name is still the tenant name followed by the word default, they assume it is the corporate platform.

The default environment is where people learn and where small things live. It is also where the expense approval flow started. So the second half of the rule is a path out. When something built there gains a second team of users or a data dependency from another system, it moves into a shared environment with an owner. Governance that keeps low-code work moving covers how to run that intake without turning it into a review board.

One thing I say plainly in the meeting: if a business process today depends on something in the default environment, that is an incident with a date you have not been told yet. Find those first. The admin center's app and flow lists, sorted by how widely each is shared and which connectors it uses, will surface the top twenty in an afternoon.

Shared environments need an owner and a promotion rule

Once a solution has earned its own pipeline, the question becomes who approves the move from dev to test and from test to production. My default answer is that makers own dev, the solution owner approves test, and the platform team together with the business owner of the process approves production. The approval happens in the pipeline, by a named person, with a record. A chat message that says go ahead does not count, because six months later nobody can find it.

Managed environments earn their cost at this point. Sharing limits, solution checker enforcement, and usage insights are the difference between a production environment you can defend in an audit and one you are hoping about. I do not turn managed environments on everywhere. I turn them on for production and for any environment that holds another team's data, because that is where the controls pay for themselves.

DLP policies go per environment once you have more than a handful. Production for the finance solutions allows Dataverse, the ERP connector, and Office 365 Outlook, and nothing else. A team's dev environment can be looser. A single tenant-wide policy ends one of two ways: makers blocked from everything, or makers blocked from nothing. The release checklist for shared solutions is the conversation that happens at the promotion gate. The environment strategy decides who is in the room for it.

Run the pipeline under a service principal and keep the approvals with named people. When the pipeline runs as the maker who built it, the day that maker leaves is the day production stops being deployable. I have watched that happen on a solution that fed month-end close, discovered two weeks before the close.

Write the inventory down and put a review date on every row

The document that makes all of this real is an environment inventory. One row per environment: the name, the purpose in one sentence, an owner and a backup, the DLP policy, whether it is managed, which solutions live there, capacity used, and a review date. Keep it in a Dataverse table or a list the platform team owns. A slide deck from the original design workshop is where these go to die.

The review date is the part people skip and the part that matters most. At each review the owner confirms that the purpose still holds and that the solutions listed are the solutions present. When the last solution leaves an environment, the environment goes too. Capacity is the obvious reason. The better reason is that an environment with no solutions and no owner is where the next shadow process gets built, because it looks empty and nobody is watching it.

A small platform team can own that inventory without owning every solution in it, which is the split the case for a small center of excellence argues for. The team owns the rows. The people named in the rows own what is inside. Here is what I ask about each row at the quarterly review.

  • Who is the owner, and did they reply to the review request within the week?
  • What is this environment for, in one sentence, and do the current contents match that sentence?
  • Which DLP policy applies, and when was it last changed, by whom?
  • Which solutions here have a production dependency from another team?
  • How much capacity is used, and which solution is driving it?
  • Is there a reason for this environment to exist next quarter?

Start by counting what you have

The next step is to open the admin center and list your environments. For each one, try to name the owner and the purpose in under a minute. Every environment where you cannot is a meeting you need to have before you create another one. If the count comes back at one, you know which extreme you are at. If it comes back at sixty, you know too.

Either way the first meeting is the same. Pick the ten solutions with the widest blast radius, using the four questions, and give each one an owner and a home. The rest of the work in the DevOps and ALM hub gets easier once those ten have a pipeline and a name against them.