Dynamics CRM solution can be defined as a pack of different customizations that can be easily moved between different databases. Depending on the project you are currently working on (be it a sandbox or not), there are two types of solutions to handle: managed and unmanaged.
Generally speaking, solutions are used to transport apps and components from one environment to another plus apply any customizations you already have to existing apps. They can contain metadata as well as entities with configuration data, although not business data.
Both managed and unmanaged solutions can include different components like Microsoft Power Platform, model-driven apps, flows, entities, and more. They are packed as a unit to be exported and imported easily to other environments, as well as deconstructed and checked into source control as source code for assets.
Solutions Publishers
Whatever you create, be it an app or other component like tables, customizations, etc. – is part of a solution. Furthermore, since every solution has a publisher, you always want to create your own publisher instead of using the default right at the beginning, when you first create a solution.
The publisher reserves the ownership of a component as well as controls what changes other publishers can make to your solution, including what components are allowed to make or restricted from making.
In case you need to move ownership of a component from one solution to another – you can do that within the same publisher, but not across publishers. Because once you set the publisher for a component – there is no way to change the publisher for the component. Meaning always defines a single publisher, so there is an ability to change the layering model across solutions later.
An unmanaged solution publisher does not own the component, so when you convert to managed, you are setting the owning publisher.
Solutions Lifecycle
You can create, update, upgrade and delete solutions.
When Creating a solution, you also first initiate a new solution. You are now entitled to associate it with a publisher plus able to add components.
Then, Updating the solution is the ability to update the target environment with a higher version of components or simply add additions.
Lastly, Upgrading – similar to an update, it gives the ability to import a higher version number solution plus remove any components that no longer comply with the solution. Means, use an upgrade on those target environments which have components to delete.
Solution Segmentation Strategies
Solution segmentation strategies typically involve the separation of components, either via component type or business area, although oftentimes, there is a combination of the two.
Implementations have often defined segmentation strategies as a workaround to achieve faster solution deployment times to minimize business impact during deployments. Now, recent investments and subsequent improvements have been made to the solution import performance, reducing the need for the segmentation of performance benefits.
It is recommended to use segmentation for different apps or business areas if they require different deployment teams and deployment cadence.
Note: It does make sense for some components, such as connection references and PCF controls, to be in their own solutions.
Unmanaged vs. Managed Solutions
The solution can be either managed or unmanaged.
Unmanaged solutions are used in development environments where you make changes to your application. It can be exported as either unmanaged or managed. Unmanaged versions of the solution should be checked into source control – not just a zip file but also the unpacked raw XML files.
Unmanaged solutions should be considered your source of Microsoft Power Platform assets. When an unmanaged solution is deleted, only the solution container is deleted, meaning the actual customization or introduction of those components will still be affected in the default solution. The deletion of an unmanaged solution will not delete the associated components.
Managed solutions are what is recommended to be used to deploy environments that are not developing ones. It would typically include UAT, SIT, and production environments. A managed solution can be serviced independently from other managed solutions in an environment such as an ALM. Following the best practice, managed solutions should be generated by exporting an unmanaged solution as managed and considered a build artifact.
You can’t edit components directly within a managed solution. Editing of a managed component can only be done in the associated unmanaged solution in a development environment or by adding the components to an additional unmanaged solution in Dev, which will then create a dependency between the two solutions.
When a managed solution is deleted, which would be the uninstall action, all customizations and extensions included are also removed.