The Solution Layer Cake: Understanding D365 & Dataverse's Secret Sauce

You know, after working with hundreds of Dynamics 365 and Power Platform implementations, I've realized that many of the headaches people encounter boil down to one thing: not understanding how solution layering works. Let me pull back the curtain and save you some pain.

Since day one, if you asked someone from Microsoft about unmanaged solutions in production they have said "don't do it". Yet they did not prevent it and many consultants found that the simplicity was worth the risk. This post is not about relitigating that argument. I could agree with you that unmanaged in production is fine, but then we would both be wrong.

The Layer Cake Nobody Told You About

Think of solutions as a layer cake where Microsoft baked the bottom layer, and everyone else is piling on toppings. At its core, solution layering is pretty simple:

1. The Bottom Layer - Microsoft's system layer with all the vanilla functionality
2. The Middle Layers - All your managed solutions stacked in order of installation
3. The Frosting - Your unmanaged customizations sitting pretty on top

What's fascinating (and frustrating) is how these layers interact. Let me break it down in plain English.

Managed Solutions: The Building Blocks

I like to think of managed solutions as LEGO blocks that snap into your Dataverse environment. Once they're in, you can't modify them directly - they're locked down tight. RapidStart Apps and other ISV solution sit here for example.

When you install multiple managed solutions, they stack on top of each other based on when they were installed and their dependencies. If you've got Solution A customizing the Account entity, and then you install Solution B that also tweaks Account, Solution B sits on top and wins any conflicts.

Here's where it gets interesting - this isn't a "winner takes all" situation. Some properties merge, others override. I've seen plenty of folks pull their hair out because they didn't realize that form sections might merge while display names override.

Unmanaged Solutions: The Wild West

Now, unmanaged solutions are a different animal altogether. Think of them as the wild west of your Dataverse environment. While managed solutions create their own distinct layers in the cake, all unmanaged solutions exist in a single layer at the very top.

This is crucial to understand: If you have 5 different unmanaged solutions, they're not creating 5 different layers. They're all dumping their customizations into one big pot at the top of the stack.

The real kicker? If two unmanaged solutions modify the same thing, the last change wins. Period. No fancy merging algorithms here - it's survival of the latest.

The Dance of Installation and Updates

Let's talk real-world scenarios. What happens when you install a new managed solution that touches components you've already customized in your unmanaged solutions?

Your unmanaged customizations stay king. The managed solution slides into the layer cake below your unmanaged layer, but users still see your unmanaged version. The managed solution's version is there, lurking in the shadows, but it won't show its face unless you remove your unmanaged customizations.

And updates? When you update a managed solution, it replaces its previous version at the same layer position. It doesn't create a new layer - it's more like swapping out ingredients in the middle of your cake without disturbing the overall structure.

The Removal Gotcha

Here's a critical gotcha that's burned countless organizations: removing a managed solution when you have unmanaged customizations to it.

Let me be crystal clear - when you remove a managed solution, any unmanaged customizations to its components go straight to the digital graveyard. They're gone. Kaput. No recovery.

Why? Because those unmanaged customizations are just modifications to the base components. Remove the foundation, and the modifications have nothing to stick to.

I've seen projects go sideways when someone decides to "clean up" solutions without understanding this fundamental concept. Don't be that person.

The Dependency Web: When Solutions Get Clingy

Let's talk about dependencies - the invisible threads that can make or break your D365 implementation.

In the solution world, dependencies are like family relationships. Once established, they're hard to break. When Solution A depends on Solution B, you can't just kick Solution B out of the house without creating chaos.

Here's what you need to know:

1. One-Way Street - Dependencies only flow upward. Higher layers can depend on lower layers, but not vice versa. This means your ISV solution can depend on Microsoft's base functionality, but Microsoft doesn't depend on your ISV.
2. The Dependency Chain Reaction - I've seen entire projects derailed because someone didn't map out the dependency web. You try to remove one solution, and suddenly you're facing a wall of dependency errors that would make your head spin.
3. Solution Segmentation Is Your Friend - Break larger solutions into smaller, more focused ones with clear dependencies. It's much easier to manage ten small, purpose-built solutions than one massive solution that does everything.
4. The Hidden Dependencies - Some dependencies aren't obvious. That innocent-looking workflow might secretly depend on a field from another solution. Always, always use the dependency checker before making major changes.
5. Circular Dependencies Are the Devil - If Solution A depends on B, which depends on C, which somehow depends back on A... congratulations, you've just created a nightmare. Avoid circular dependencies at all costs.

I remember one client who ignored my advice about mapping dependencies before a "simple cleanup." Three days of emergency weekend work later, they became believers. Don't learn this lesson the hard way.

The Unmanaged Solution Shuffle: Breaking Up Is Hard to Do

Let's talk about something that gets overlooked until it's too late: removing unmanaged solutions and their components. This is where things get really interesting (and by "interesting," I mean "potentially disastrous").

When you delete an unmanaged solution, here's what you need to know:

1. Component Ownership, Not Deletion - Deleting an unmanaged solution doesn't automatically delete its components from your system. It just removes the association between the solution and those components. The components become "solution-less" orphans floating in your system.
2. The Component Shuffle - If a component is used in multiple unmanaged solutions, it officially "belongs" to only one of them. When you remove that solution, the component ownership shuffles to another unmanaged solution that uses it. It's like a game of musical chairs.
3. The Real Delete - Want to actually remove a component? You need to: Remove it from ALL unmanaged solutions that include it Explicitly delete the component itself from the system Publish your customizations
4. The Managed Component Twist - If you've added managed components to your unmanaged solution (yes, people need do this to customize managed components), deleting the unmanaged solution doesn't touch the managed components. They stay right where they are.
5. The Gotcha Moment - Ever deleted an unmanaged solution, breathed a sigh of relief that everything still works, then months later wondered why your system is full of unused components? Now you know why.

I once watched a client delete their "test" unmanaged solution thinking it would clean up all their experimental components. But that is not how it works. Those components lived on, causing confusion in their production environment for months.

My Advice After Hundreds of Implementations

After seeing the good, the bad, and the ugly across hundreds of projects, here's my battle-tested advice:

1. Treat your production environment like a temple - managed solutions only, please.
2. Use development environments for your unmanaged work - that's what they're for.
3. Document which components belong to which solutions - your future self will thank you.
4. Test every solution update in a sandbox first - every single time, no exceptions.
5. Take screenshots before and after significant changes - trust me on this one.

The organizations that thrive with D365 and Dataverse are the ones that respect the layer cake. They understand that it's not just about dumping in customizations - it's about carefully constructing a stable, maintainable environment that can evolve over time.

So next time you're about to import that solution, take a moment to consider where it fits in your layer cake. Your sanity (and your users) will thank you.

Pro tip! If you want a quick litmus test on the skill and competence of your consultant, check your production environment for unmanaged solutions.