Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, 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 Apps release plans, docs repo and product blog, plus the author's own consultant notes.

feature-solutions-for-apps.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn

What it does

The container that lets a canvas or model-driven app move between environments with its tables, flows, connection references and environment variables intact. Apps built outside a solution are stuck where they were made, and getting them out later is manual rework.

Key facts

  • A canvas app can only be added to a solution if it was created from within one. Add existing lists only apps that already originated in a solution — there is no route back for an app built in the standalone maker experience.
  • You can't generate a three-screen app, or start from a template or sample, from inside a solution. Solution-based canvas apps start blank.
  • Managed properties let you lock components so they can't be customised downstream. Microsoft's guidance is to set them, so a managed component can't be modified into a broken state in test or production.
  • Editing a managed component in a target environment creates an unmanaged layer over it, and that layer then blocks uninstalling the managed solution until it's removed.
  • Model-driven apps, forms and site maps merge across layers. Everything else is top-layer-wins.
  • The publisher prefix is stamped onto logical names at creation and can't be changed afterwards. Set it before anyone builds anything.
  • Components created outside a custom solution land in the default solution with a random prefix like cr8a3, and keep it permanently.
  • A solution is capped at 95 MB, and large canvas apps consume that faster than anything else in the container.
  • Canvas apps shared with Everyone lose that sharing through an environment backup and restore. Sharing with a security group survives it.
  • Flows called from a solution-based canvas app must be shared explicitly with the app's users — sharing the app doesn't share the flow.

When to use / skip

Every app that a business will depend on goes in a solution, from the first screen. The canvas app rule makes this sharper than it is for flows: a canvas app created outside a solution can never be added to one, so "we'll tidy it up later" isn't a plan, it's a rebuild. The only defensible exception is genuine personal productivity in the default environment, where nothing will be promoted and nobody but the maker cares. If you inherit an estate of standalone canvas apps, price the remediation as a project rather than promising to fold it into delivery.

Configuration decisions

  • The publisher and prefix, agreed before build starts, since they're permanent and visible in every logical name for the life of the system.
  • Where the solution boundaries fall — usually by release cadence and lifecycle rather than by feature or by app.
  • Whether makers get a preferred solution set so stray components stop landing in the default solution.
  • Which managed properties to set on components you're shipping, and whether the client's own team is expected to customise them downstream.
  • Whether canvas apps are forced into solutions by policy from day one, given there's no retrofit path.

Gotchas

  • The canvas app one-way door catches almost every project once. Someone builds a proof of concept in the standalone experience, the business likes it, and it can't be promoted.
  • Large canvas apps eat the 95 MB solution cap quickly, and it tends to bite on the release you least want to debug.
  • A canvas app that references a deleted flow fails to publish with an error about connections to flows no longer in the environment. Remove the reference, then save and publish.
  • Sharing an app with users doesn't give them the flows behind it. The app appears to work in dev, where the maker owns everything, and fails in test.
  • Deleting a managed solution uninstalls its components and destroys data in the custom tables and columns that came with it.

Consultant notes

  • Write "canvas apps are created inside a solution, always" into the project standards in week one and make it a review gate. It's a five-second habit that prevents a rebuild.
  • Sell managed solutions in production as change control rather than technical preference. "Nobody can edit this in production" is the sentence that gets sign-off from a risk function.
  • Agree the publisher prefix with the client, not for them. It's permanent, it's visible forever, and they'll notice it eventually.
  • Warn that deleting a managed solution takes the data with it. That one sentence has prevented more than one production incident.

Worth revisiting if the 95 MB cap moves, or if canvas apps ever gain a supported route into a solution after the fact.

Was this accurate?