Almanac

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

feature-solutions-overview.mdv1 · history
CurrentApplies to AllUpdated last monthSource Microsoft Learn

What it does

A solution is the container Dataverse uses to track, package and move everything you build — flows, apps, tables, connection references, environment variables. It's the transport mechanism for application lifecycle management on Power Platform, and the only supported way to get a flow from one environment to another with its dependencies intact.

Key facts

  • Solutions are either unmanaged or managed. Unmanaged is what you develop in; managed is what you deploy. You export an unmanaged solution as managed — you can't export a managed one.
  • You can't import a managed solution into the environment that holds its originating unmanaged solution. Testing a managed build needs a separate environment.
  • Deleting a managed solution uninstalls its components and destroys data in custom tables and custom columns that came with it. Deleting an unmanaged solution only removes the container.
  • Layering is per component. All unmanaged solutions share one unmanaged layer; managed solutions stack, last installed on top. Except for model-driven apps, forms and site maps, behaviour is "top layer wins" rather than a merge.
  • Every solution has a publisher, and the publisher owns every component created in it. Once a component ships in a managed solution you can't change its publisher, and you can't move ownership across publishers.
  • The publisher prefix is stamped onto metadata names at creation and can't be changed afterwards. Set it before anyone builds anything.
  • A solution is capped at 95 MB. The number of solutions and objects is bounded by Dataverse capacity rather than a fixed count.
  • Microsoft's own guidance says patches aren't recommended. Use updates and upgrades.

When to use / skip

Put flows in a solution from the first day of the project, always. There is no realistic path back — a flow built outside a solution keeps using direct connections rather than connection references, and retrofitting the estate later is a week of tedious rework you won't have budgeted. The only place you'd reasonably skip solutions is genuine personal productivity in the default environment, where nothing is going to be promoted and nobody but the maker cares. Everything else that a business will depend on belongs in a solution with a proper publisher.

Configuration decisions

  • One publisher for the whole organisation versus a publisher per delivery team, remembering you can't change publisher on a managed component later.
  • The prefix itself, which will be visible in every logical name for the life of the system, so keep it short and boring.
  • How many solutions to split the estate into, and where the boundaries fall — usually by lifecycle and release cadence rather than by feature.
  • Whether makers get a preferred solution set in their environment so stray components don't land in the default solution.
  • Whether tables get segmented on export so you're shipping only the columns you changed rather than whole entities.

Gotchas

  • Components created outside a custom solution land in the default solution with a random publisher prefix like cr8a3. Everything built that way inherits that prefix permanently.
  • Editing a managed component creates an unmanaged layer over it in the target environment, and that layer then blocks uninstalling the managed solution until you remove it.
  • Segmenting a table that doesn't exist yet in the target gives you a missing dependency error on import. New custom tables need all objects included.
  • Solution dependencies are enforced in both directions — you can't install a dependant solution before its base, and you can't uninstall the base while the dependant is still there.
  • The 95 MB cap is real and large canvas apps eat it quickly. It tends to bite late, on the release you least want to debug.

Consultant notes

  • Agree the publisher and prefix in the first week and write it into the project standards. It's a five-minute decision that's permanent, and getting it wrong is visible in every logical name forever.
  • Sell managed solutions in production as change control, not as a technical preference. "Nobody can edit this in production" is the line that gets sign-off from a risk function.
  • Warn the client that deleting a managed solution takes the data with it. That sentence has saved more than one production incident.
  • If you inherit an estate built in the default solution, price the remediation honestly rather than promising to tidy it up alongside delivery. It's a project, not a task.

Worth revisiting if the 95 MB solution cap moves, or after the next release wave changes layering behaviour.

Was this accurate?