Solutions are the unit of Power Platform deployment (3/15)

If environments are the road, solutions are the vehicle. Everything you want to move — tables, apps, flows, agents — travels inside one. The question is not whether to use solutions. It is where to draw their boundaries.

What a solution boundary decides

A solution packages Dataverse tables, apps, flows, agents and other components so they move together. The boundary decides three things at once: what can be reviewed, what can be versioned and what gets deployed alongside it.

Draw it too wide and one release drags unrelated work along for the ride. Draw it too narrow and you spend your time sequencing dependencies between a dozen small solutions.

Publishers are not a formality

Every solution has a publisher, and the publisher's prefix ends up on every component you create. Pick a meaningful prefix and use it consistently. When I open an environment and see three different prefixes for the same project, I already know the next deployment will have surprises.

Managed out, unmanaged in

The pattern that has served me best is simple:

• Keep development work in an unmanaged solution in the development environment.
• Export a managed solution as the release artefact for every environment after development.
• Never treat unmanaged changes in test or production as part of the release. They are drift.

Managed solutions make the target environment predictable. They also make the next part of the series — solution layers — much easier to reason about.

Group by business capability

Group components by what they do for the business, not by the order they were created. "Supplier onboarding" is a useful boundary. "Everything Tom built in March" is not.

A good boundary passes a simple test: another team can understand what the solution owns without opening every component.

One giant solution is hard to own, and twenty fragments are hard to sequence. Both are signs that nobody decided the boundary on purpose. I would rather spend an hour agreeing the boundary than a day untangling it later.

A practical next step

Take one solution and write down five things: its business purpose, publisher, dependencies, owning team and target environments. If any of those is hard to answer, that is where the boundary needs work.