How to Select Between Managed and Unmanaged Solutions

The debate about using Managed Solutions vs. Unmanaged solutions will not continue here. We recognize there is a time and place for each, and it is not a simple matter of one is better than the other. We must consider each organization’s unique needs and determine which approach fits their application lifecycle.

This post is intended to provide guidance on when to use Managed or Unmanaged solutions. The platform cannot function optimally when using a mixed approach for customizations. Now there will be managed solutions that are part of third-party vendor (ISV) solutions. However, when dealing with configurations and customizations performed directly for an organization the approach must be consistent either managed or unmanaged, not both.

Why Not Both?

This is a good question. The issue is unmanaged solutions modify the default solution immediately upon being imported creating what is called an Active Layer. All unmanaged solutions share the same unmanaged layer. While managed solutions layer one on top of another with the result being last one in or top one wins. The active layer (unmanaged layer) sits on top of the managed solutions and trumps any changes that exist within those solutions. Therefore, the system admin would be chasing their tails trying to understand which customizations are showing if the environment had a mix of unmanaged and managed solutions.

Below is a model of how the layering works.

Choose One

The solution to this is to choose one path or the other. If the environment already has unmanaged solutions pushing updates to production, then stick with unmanaged solutions. Otherwise, you would have to wrangle all customizations into a managed solution and remove all the active layers created by the several different unmanaged solutions.

If an organization is large and has a very structured deployment process, then managed solutions would fit nicely. Work with unmanaged solutions in Dev, export those as managed and import to higher environments as part of the application lifecycle.

If an organization is promoting small feature releases, then unmanaged solutions would fit better. This is due to the idea that you create several solutions to fit whatever feature push is current and ready to go. You could have work performed in parallel in different solutions.

Keys to a Managed Environment

Some things to keep in mind when working with managed solutions:

1. Use a single publisher across all environments

2. Use least number of solutions

Place all customizations and configurations within one solution file and continue to use that same solution file throughout the project.
Avoid multiple solutions modifying the same component
- Don’t have two different solutions where both contain tables
  - This create cross-solution dependency
- At some point end that solution file at the end of the implementation or major project or each year. Then create a new solution to work with for the next development cycle.

3. Merge only occurs for model-driven apps, forms, and site map

When working with forms create new when possible
- When modifying forms that come with Dataverse or D365 CE out of the box, a merge must occur and this can cause conflicts.
Only one SiteMap customization can be applied between publishing.
- Any unpublished SiteMap customizations will be lost when a new SiteMap definition is imported.

4. Segment Solutions

Include no components or metadata
Only include components that are updated
Include entity metadata
- This involves no components but includes metadata associated with the entity, such as auditing, duplicate detection, and change tracking.

Final Word

Managed and Unmanaged Solutions, although they work well separately, cannot ideally function together. Dynamic Consultants Group considers each organization’s specific needs and which approaches fit their application lifecycle best. Allow our experts to provide the solution management your platforms require. Schedule a meeting today to learn how to get more value for your system.