Power Platform Solutions - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. The app you spent months building can disappear the moment someone uninstalls the wrong thing. That happens when nothing is holding the app's pieces together, so one cleanup can take the whole thing with it. In Power Platform, the thing that holds it together is called a solution. You might think a solution is just a folder, but it works more like a shipping manifest that lists every part your app needs. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. By the time we're done, moving, an app between environments will feel like a routine, not a gamble. What a solution actually is. Start with the word itself, because it trips people up more than any other term in this space.

0:42 In everyday language, a solution is the answer to a problem and inside power platform it means something much narrower. Once you see the real meaning, the rest of this topic gets a lot easier to follow. A solution is a container. It's the box that carries your app along with every piece that app depends on, from one environment to another. If your app were a chair, the solution would be the crate you ship it in with a list taped to the side of everything packed inside. That list matters more than it sounds inside a solution, you can put canvas apps, model driven apps, cloud flows, tables, forms, columns, choices, charts, custom connectors, and web resources. Anything you can customize can be a component, and the solution keeps track of all of them together, so nothing gets left behind when the box moves. Some of those components live inside others, which is worth knowing before you start counting.

1:24 A single table contains its own forms, views, charts, columns, and business rules, and almost none of those pieces can exist outside that table. A column can't exist without its table. The same way a drawer can't exist without a dresser, and the platform tracks that relationship for you. A solution carries the recipe and the settings, and it doesn't carry your actual business data. It holds the metadata plus certain tables that store configuration, but it never holds the customer records or the invoices themselves. When you move a solution, you're moving the design of your app, not the contents of its database. There's a practical limit here to a single solution can be up to ninety five megabytes in size, which sounds generous until you pack an entire business process into one. When a solution gets heavy, it gets slower to export and import, and that slowdown is usually a sign it's trying to do too much at once.

2:06 Now think about how almost everyone actually starts. You sign in, you find an environment you're allowed to click into and you build. Nobody hands you a solution on the first day, so the app grows up loose with its pieces scattered across that environment. That work still runs, but moving it later is painful, and tracking what changed along the way is close to impossible. So the first habit is simple and it costs you almost nothing. Before you build something real, create a solution and put your work inside it from the very start. Managed and unmanaged. The two modes. Here is where the confusion usually begins. There are two kinds of solutions managed and unmanaged, and the names tell you less than they should. Unmanaged is the version you edit. You use it in your development environment while you're still building, testing and changing your mind, and every tweak you make lands directly in the app.

2:49 Unmanaged is your working copy managed? Is the version you deploy. It travels to every environment that isn't your development environment for that solution, which includes test user acceptance, testing, system integration, testing, and production managed. Is your finished copy frozen and ready to ship? One clean way to hold both in your head is this unmanaged? Is edit here managed is deploy there. If you remember nothing else from this episode, remember that pair. The difference that catches people is what happens when you delete them. Delete an unmanaged solution and only the container disappears because the customizations stay exactly where they are and quietly fall into the default solution. Delete or uninstall a managed solution. And the opposite happens because everything inside it gets removed.

3:30 That removal takes data stored in custom tables that were part of the solution, along with data in custom columns on other tables. That's real data gone, and there's no undo button to press. There's another rule that surprises newcomers. You can't import a managed solution back into the same environment that holds the unmanaged one you built it from, so testing the managed version requires a separate environment. This is the reason the very first thing you set up is a second environment, not a second solution. Managed solutions are also locked by design. You can't edit components directly inside a managed solution. And to change one, you first add it to an unmanaged solution. That move creates a dependency between your change and the managed solution, and the dependency then has to be cleared before the managed solution can be uninstalled. And one more because it answers a question you're probably about to ask.

4:12 You can't export a managed solution. What you can do is export an unmanaged solution as managed, and that single step is how the deployable copy gets made. The reason this split exists at all is that unmanaged is your source and managed is your build. Microsoft says to check the unmanaged version into source control, and to treat the managed version as a build artifact that the system produces for you. That one habit turns a pile of clicks into something. You can actually track publishers and prefixes. Every solution carries a label, and that label is the publisher. The publisher is the person or the organization that owns the components sitting inside the solution. Ownership isn't a formality here, because the publisher of the solution, where a component was created, controls what other publishers are allowed to change. You can move a component between solutions that share the same publisher, but you can't move it across publishers.

4:57 The publisher also carries a prefix, which is a short tag that gets stuck on the front of the names the platform creates for you. Like the prefix on a custom table or a custom column. Its job is to keep names from colliding when solutions from different publishers live in the same environment. Two teams can both build something called a customer table, and the prefix is what stops them from fighting over the same name. Now for the part people regret. Once a publisher is introduced for a component inside a managed solution, you can't change it. And you should set the prefix before you create any apps or metadata, because you can't rename those items afterward. Pick a prefix on day one that actually means something like your company initials, and you'll never have to think about it again. This is also why the guidance is so direct about using one publisher. Every solution you build across every environment should come from the same publisher that keeps ownership clean.

5:41 It keeps your prefix consistent, and it lets you change how your solutions layer later without reopening decisions you already made. When you create a publisher. Give it a name. A stranger could understand because that name shows up as who developed the app. You're not naming a folder here. You're signing the work. If you've already built things under the default publisher. You're not stuck forever. You can create your own publisher today and use it for everything new. The goal is not a perfect past and the goal is one publisher going forward. Moving your app between environments. Now we get to the trip itself. An environment is a space that holds your data, your apps, and your business processes, and it separates work that has different roles, security needs, or audiences. Each environment can hold only one Dataverse database, so the environment is the unit you plan around, and the solution is what travels inside it.

6:25 You'll meet a few kinds of environments along the way. A sandbox is any non-production environment, and it's the safe place to develop and test because it supports reset, delete and copy. Production is where the apps actually run for the people who need them. A developer environment is a single user space meant for building and learning, not for running a real app. And the default environment is the one shared by everyone in your tenant. The standard set you build toward is three. Development is where makers build. Test is where you prove that the app works and that the deployment itself works. And production is where real people use it every single day. The move goes like this. You build your unmanaged solution in development, then export it as managed and import that managed solution into test. Once it checks out, you import the same managed solution into production.

7:05 Every hop carries the same frozen copy. So the thing you tested is the thing you ship. Power platform gives you four actions for managing the life of a solution, and the word sounds similar enough to blur together. So let me pull them apart. Create is authoring your unmanaged solution and exporting it. Update pushes changes onto an existing managed solution and it can't delete components. So it's for additions and edits. Upgrade replaces the old version with a new one and does remove components you dropped, which is why upgrade is the honest way to retire something. Patch is a small hotfix layered on top of a parent solution, and Microsoft doesn't recommend it, so treat it as a rare exception rather than a habit. There's one version rule worth tucking away. You can import a solution into an environment that is newer than the one you exported from, and that direction is safe.

7:47 You can't reliably import into an environment that is older because pieces the solution depends on may not exist there yet. This isn't exotic work, and it's the same discipline any software team already follows. Build in one place, prove it in another, and only then let people use it. Solution layers. This is the point where the platform stops feeling like a set of folders and starts feeling like a stack of transparencies. Layering happens at the component level, not at the level of the whole solution. Picture one specific form or one specific column and understand that it doesn't have a single definition. It has a stack of definitions, and the one at the top of the stack is the one the app actually uses. In Dataverse, there are two broad levels everything unmanaged, meaning every imported unmanaged solution, plus every ad hoc customization you made by hand shares one single unmanaged layer managed solutions each get their own layer, and the last managed solution you install sits on top of the ones installed before it.

8:38 At the very bottom is the system layer, which holds the tables and components the platform itself needs in order to run. So when two managed solutions define the same thing differently, the result depends on the component only. Model driven apps, forms and sitemaps actually merge, blending the two definitions together. Everything else follows a simpler rule the documentation calls top wins, where the layer sitting on top decides how the component behaves at runtime. That one idea explains a lot of strange behavior. An app that worked perfectly yesterday can behave differently today because a new managed solution landed on top, and one uninstalling works the same way in reverse. Remove a managed solution and the one below it takes over and remove them all and you fall back to the default sitting in the system layer. There's also a stack inside each managed solution.

9:20 At the bottom sits the base layer, which carries the publisher and the managed properties. On top sits the current layer which defines the behavior you see right now. And you can get patch layers and a pending upgrade layer stacked above that if someone staged an upgrade. Microsoft advises against patches, so in healthy work, you rarely see more than a base and a top. The lesson is short. A component is never really one thing, and it's whatever the top of its stack says it is. Dependencies why you sometimes can't remove things. Layers explain how solutions interact and dependencies. Explain why the platform sometimes refuses to let you remove one at all. Because managed solutions are layered, one managed solution can depend on components that live in another managed solution. Vendors use this on purpose shipping a base solution, and then a second solution that extends it, where the second one declares that it needs the first.

10:06 The platform tracks those links and it enforces them in both directions. If you try to install a solution that needs a base solution, you don't have. The install is blocked until you add the base. The reverse is just as firm because you can't uninstall the base solution. While a solution that depends on it is still installed, you have to remove the dependent solution first. The trap worth watching for is a circular dependency. Imagine two solutions from two different publishers, where each one extends a component that the other one owns. Now, neither solution can be uninstalled or upgraded because each one is waiting on the other to go first, and the platform won't let you do either. That's a genuine dead end, and it's the strongest argument for keeping your solution count low and your publishers aligned dependencies also exist inside a single solution between the components themselves.

10:48 A cloud flow that triggers on a custom column depends on that column. A security role for a custom table depends on the table, and a form depends on the table it displays. You'll run into this the moment you try to remove something and the platform asks you to remove its dependence first. When that happens, the fix isn't to fight the platform. You find the dependence. You decide whether they still belong and you remove them in the right order. The platform is simply asking you to look before you delete. None of this is the platform being difficult. It's the platform protecting you from deleting the flaw that a load bearing wall is standing on. L'm best practices for beginners. So here is what you actually do. And the list is shorter than it looks. First, separate your environments. You need development and production at a minimum. And the guidance is blunt that healthy practice includes a test environment before anything reaches production.

11:32 You want to prove that the deployment works and that the app works because deployments are where the surprises live. Second, keep the unmanaged solution in development as your source of truth. Check it into source control so you have a history of every change, and treat the managed solution as a build artifact that you generate rather than hand edit. You build in the unmanaged copy and you ship the managed copy. Third, use one publisher for everything and decide the prefix before you build anything real. That's the cheapest decision to get right and one of the most expensive to get wrong. Fourth, pick a solution strategy that matches your size. One solution is the simplest choice, and it's fine for small and medium work, as long as you're not planning to split it up later. If you genuinely need multiple solutions in one environment, keep all your tables in a single solution.

12:13 Never put the same component in two solutions and avoid dependencies between them, because that's exactly where import order and circular locks come from. Large teams with strict rules often give each solution its own development environment and layer a base solution underneath, which takes more work but scales far better. Fifth, don't build in the default environment. Create environments for a purpose and give the right people the right access. With makers and development testers and tests and users in production, the default environment is shared by everyone in the tenant, and that's the last place you want your first real app to live. And sixth, keep the number of solutions as small as you can while still keeping things manageable, because every extra solution is another chance for a dependency you didn't plan for. There's a way to make all of this automatic.

12:54 Once you're ready, you can connect your solutions to source control and use a build pipeline to export package and deploy them. So the move from development to production becomes a button rather than a checklist. You don't need that on day one, and it's worth knowing it exists before your fifth app, not your first. Put those habits together and you have application lifecycle management, which is a brand name for a simple promise. What you tested is what you shipped. A quick recap and one question. Let me pull the whole picture together and I'll keep it quick. A solution is the container that carries your app and every part it needs. Unmanaged is where you build and managed is what you ship. The publisher and its prefix are the label you commit to early because they follow your app around for good layers. Decide which definition wins when solutions overlap and dependencies decide what you're allowed to remove.

13:38 That's the entire mental model, and it's enough to keep you out of almost every trap this topic has. Subscribe to M365 FM if you want more of the tools and the mindset shaping the future of work, here's the question I'll leave you with. If you opened your environment right now, would you find a solution holding your work together? Or would you find work sitting loose in the default with nothing to catch it?