I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around solutions.
You can see below that we have a section of the exam which covers discovery, planning and analysis, within this section needing to know how to select between managed and unmanaged solutions is mentioned. This statement actually implies quite a large amount of knowledge! As to select between solution types you’d need to appreciate what solutions are, how they are used and all of the differences between their managed and unmanaged versions.
![]()
Overview
Solutions in Dynamics 365 are used to package and deploy customizations. Changes are grouped together as a solution, they can then be exported and transported from one environment to another.
The solution will include entities and their assets. The assets include Forms, Views, Charts, Fields, Keys, Relationships (1:N, N:1 and N:N), Messages, Business Rules, Hierarchy Settings and Dashboards. But solutions contain much more than “just” entities. Other options include Web Resources, Workflows, System Dashboards, Connection Roles, Security Roles, SLAs, Apps etc etc. I will discuss more on what can be included later. But for now, it is enough to understand that solutions can include A LOT of different types of components.
Components within a solution can include;
- Schema components, including entities, fields, relationships and global optionsets.
- User Interface components, including forms, view charts, dashboards, site map, web resources and ribbons.
- Analytics, includes dashboards, reports and other visualizations.
- Process / Code, include processes (e.g. workflows) plus plug-in assemblies.
- Templates, including email templates, contract templates, KB article templates.
- Security, including security roles and field security profiles.
Solutions can be unmanaged or managed. Often unmanaged solutions are used in development but as they are deployed (or re-deployed) to production environments managed solutions are used. Managed solutions can be created in-house but they may also be used when adding functionality into the system provided by Microsoft (e.g. Unified Service Desk) or as ISV products. I will explain the differences in a second.
It is best practice to always make changes using solutions as this keeps changes together and makes it possible to track who did what.
Publishers
When you create a solution it will always have a publisher, so let’s look at those before considering how to create a new solution. When we create a solution it must be given a name and you select to either create a new publisher or select an existing one.
![]()
Why do we want a publisher? Well having a publisher(s) makes it easy to see which changes have been created by whom. As entities and fields are created their names will be prefixed to show who made the change.
A publisher might be an ISV, a Microsoft Partner or might be an internal team.
You will always have a default publisher; this could be used for internal development. Although personally, I like to avoid using the default publisher! I always create a publisher that reflects the project or organization making the change. Out of the box the default publisher will prefix all newly created fields / entities with new_.
Below you can see I have created a new publisher called “Neil Parkhurst”. The publisher name has been automatically derived from the display name.
Notice that I have set the prefix to np. Below this we can see an example of what a new entity name might look like with this prefix. (np_entity). Also notice that the Option Value Prefix is set to 77,828. Each text item in the optionset has a numeric value. The options value prefix option can be used to decide the values in optionsets for this publisher. (The option value prefix must ne in the range of 10,000 and 99,999)
![]()
If you scroll down the publisher form you will see fields to enter contact details of the publisher. These are for reference only but quite useful when the publisher is a 3rd party.
Creating a Solution
In my introduction, I mentioned a concept of the default solution. The default solution effectively an unmanaged solution containing the entire system.
Should you make changes directly in the default solution then the default publisher will be selected. Meaning any new created components will be named using new_. (At least they will be if you don’t change the out of the box prefix.)
I must admit that when I first started using “CRM” I used to make all of my changes directly in the default solution. (Shocking I know!!) These days I don’t consider that good practice nor should you.
Right from the outset I create a solution and then as I create or edit components I add them to my solution. I do this for several reasons. One being that if I try to create a solution after the change is completed I sometimes find it hard to remember all of the assets I’ve touched. But most importantly by creating your changes within the scope of a solution, all of your changes will be prefixed appropriately. (Based on your publisher.)
Below you can see that within make.powerapps.com I have opened the solutions option. Within this I have filtered to show only my unmanaged solution. It is here that we can see the “Default Solution”, along with any other unmanaged solutions.
![]()
To create a new unmanaged solution, select the “New Solution” option which is found in top ribbon bar.
![]()
As I have already suggested, when I start a new “project” I like to create my solution as the FIRST thing I do before I start making any changes. Below you can see an example solution I have created called “Neil’s Demo Solution”.
Notice the Display Name and Name are mandatory fields. The Name field will default to the display name, with spaces and punctuation removed. When you are creating a new solution you can change the name field. But once created the name field becomes read only.
I have already described the concept of publisher. When creating a solution the publisher is mandatory but will be initially populated with the details of the default publisher. You can see below how I have changed my publisher to “Neil Parkhurst”.
The configuration page is an optional field. This is a link to a web resource that will be a component of the project. This can (optionally) be used to create a html page describing the content of the solution or maybe its release history. (Or anything you feel is important.) For small projects I tend not to create a configuration page and simply type this type of information into the description field. But on larger projects when I might require more information or expect to edit it overtime I always create a configuration page.
Version, this is a mandatory field. I have simply entered 1.0.0.0. The version may auto-increment as you export changes. Plus if you import a solution and a copy ready exists you will get a message warning message which will quote this version number.
The version number can be upto four numbers separated by decimals. (e.g. 2.1.0.440) Generally this is used to reflect a major.minor.build.revision format. But alternatively you could adopt other standards such as year.month.day.revision. You also see the version number appended to the zip file name when you export the solution.
![]()
Having created a solution, you will want to start adding components. Those components can be existing or new. And can be of “any” component type. Including entities, option sets, site map, web resources, processes etc etc.
![]()
If you add a new entity you will be prompted for its name and such like. But if you add an existing entity you will get a different dialog to allow the selection of all or specific assets. Below you can see I am adding the account entity into my solution. At this point I want to select what components to add into my solution. I always suggest that it is bad practice to simply add all the assets of an existing entity into your solution, as I much prefer to only add the components that will be changed by this solution.
Tip: If you really want to add all components for an entity there is an add all components option. I just don’t use it!!
![]()
As explained, when I add a system entity I like to select the specific views, charts or forms (etc) that need to be changed. One advantage of this is that it reduces the chance of any conflicts with changes others may make.
Below you can see I have selected just the main account form.
![]()
Exporting a Solution
Once you have finished your changes you will want to be able to export the solution. (For example, So that it can be moved from your development instance into production.)
Exporting a solution is easy, simply select the solution and click the Export button.
![]()
When you do this you will asked to publish the customizations. It is important to note that only published customizations will be exported.
We also have a check for issues option. You aren’t forced to check solutions for issues but using the solution checker should be considered a good practice as it will help highlight any potential issues in your changes.
![]()
Next you will enter a version number for your solution. (This will auto increment but can be changed manually as required.)
It is here that you will select to export your unmanaged solution as either unmanaged ore managed. Notice that managed is the recommended option, this is because typically outside of your development environment the solutions would be imported in a managed state. (I will cover more about the reasons for this later in this post!)
![]()
After a pause your solution will be saved. A solution file is simply a zip file that you can then move to another environment. The fact the solution is a zip file is useful as the files created are generally pretty small and therefore easy to ship around. Also these files can be stored meaning you have a reference of what was exported when.
Importing a Solution
Having looked at how to export a solution the next logical step is to consider how it will be imported. As part of my exam revision I have actually created two trials. (You might want to do the same.) This means I can create solutions in one trial and them import them into another trial. I’ve found this approach really useful when experimenting with how solutions work.
Once you have logged into your target environment, simply select the import option.
![]()
Now browse for a solutions file.
Notice the naming convention on my solution file. As by looking at the name we can tell the solution version and also if is a managed or unmanaged solution.
![]()
Sometimes you might be prompted at this point! Say you are importing a new version of an existing solution you will get a prompt warning that you are going to replace version “1.0.0.0” (say) with version “1.0.0.1”. Check this information and click next to continue, assuming you are happy.
IF the solution new or unmanaged, you will simply progress to starting the import at this stage. Although you will get a friendly warning when importing an unmanaged solution as the changes cannot be uninstalled.
![]()
Before actually starting the Import you can select the “View solution package details” option, this will show you the components included in the solution and give you details of the publisher.
If the solution your importing is a upgrade to a managed solution you may have a decision to make!
Firstly you will decide how to import the solution. The options being upgrade, stage for upgrade and update.
![]()
Upgrade Option
With the upgrade option any existing patches are rolled up and the orginal solution will be removed after the upgrade. This process is recommended as the result should be that the resulting solution will accurately match the solution being imported. (As removing the original version will delete any components no longer in the new solution.)
The upgrade option is the recommend approach and the approach you should therefore most often use!
When we look at the solution history (shown below) we can actually see that the new solution is imported as an upgrade and then the old solution removed. This is a two step process but both steps are automatically completed by the upgrade option.
![]()
Stage for Upgrade
The stage for upgrade option effectively lets you complete the two step process of the upgrade as separate steps. Initially your new solution is imported by the old one is not removed. After the import is completed you will see both solutions. Below you can see that I have imported version “3” of my solution but version “2” is also still present.
![]()
Once I am happy the import has worked as expected I can go to the original solution and apply the upgrade. This will then remove the original solution and roll up any patches. Finally resulting in the imported solution accurately matching the exported one.
![]()
After the process has completed the solution history will show both steps. Meaning this was a manual two-step process but the end result was the same as using the upgrade process.
Update
Our final option is update. This isn’t the recommended approach!
An update simply replaces the current version of the solution with your new version. This does mean any components no longer in the new solution will not be deleted. Therefore you could end up with some inconsistencies!
Overwrite / Maintain
Below you can see that scrolling the screen down will uncover options to “Maintain Customizations” or “Overwrite”. Maintain is the recommended option, so let’s consider that first. It is possible that someone else has made unmanaged changes in the environment you are about to alter. The maintain option will try to retain any existing unmanaged changes. If there is a conflicts an existing change it will be retained and the imported one not applied.
Overwrite however would do the reverse, it effectively forces an overwrite of the new solution.
When we are thinking about a production environment, if managed correctly this type of issue should never apply. As nobody would ever make uncontrolled changes direct on a live server. But unfortunately, that is just a theory! In the real world I have often found that support guys have “fixed” a few bugs direct on the live server outside of any reasonable controls.
![]()
You will see a progress bar displayed as the solution imports. The time this takes will vary depending on the size of the solution. But typically the process only takes a few minutes.
![]()
Once completed you will get a message telling you if the import was successful. (or not!)
Tip: If you do happen to get any errors with the import the download log file option might be very useful to help you diagnose the issue.
![]()
After my solution import is completed my changes will have applied and I can also open the solution as required. If my solution was imported in an unmanaged state I could open the solution and continue to make changes. If in a managed state I will see a message that I cannot directly edit the components with the solution.
![]()
Solution History
You may find the solution history option useful. In the ribbon bar of the solutions area you will find the “see history” option.
![]()
The solution history option lets you see which solutions have been imported and if the import was successful or not. Usefully we can see details of solution upgrades that will have been completed automatically as well as manually imported solutions. If something unexpectedly changes in your environment this view is really useful to see who has applied what changes!
![]()
Managed v Unmanaged Solutions
Some points about differences between managed and unmanaged solutions;
- The default solution is always an unmanaged solution. But other solutions can be managed to unmanaged.
- Unmanaged solutions can be changed.
- Unmanaged solutions cannot be removed. (Meaning if we delete an unmanaged solution just the solution is removed all of the assets contained in the solution would remain.)
- Unmanaged solutions can be exported as managed solutions.
- Deleting an unmanaged solution has no effect on the components it contains, the delete simply removes the solution.
- Managed solutions can be removed, a process that removes the solution and its components.
- Managed solutions cannot be exported.
- When importing a managed solution, you can opt to maintain or overwrite any unmanaged changes.
- Importing an unmanaged solution always overwrites.
You always work with unmanaged solutions in development environments. But as you progress into controlled environments for user acceptance testing and production then managed solutions are often the recommended approach.
Patch Management
Patch management helps make applying revisions to existing solutions easier. One or more patches to a solution can be created from a solution and later rolled up (merged) back into the main solution.
Patches can be created from unmanaged solutions and applied to managed or unmanaged solutions. But unmanaged patches should not be used for production purposes.
Patches are only created from the parent solution. A parent solution can have multiple patches but a patch cannot have a patch. Each patch can only have one parent.
Because patches are dependent on the parent solution you can only import a patch if the parent is already present.
A patch version must always have the same major/minor version number as the parent solution. But the build / revision number must be higher. (e.g. A patch for a solution with a version set to 1.0 would be 1.0.1.0) If more than one patch is created subsequent patches will have a higher version. (So in the example just given a second patch to the parent solution 1.0 would become 1.0.2.0)
To create a patch, you select the parent solution and select the “Clone As Patch” option.
![]()
![]()
A dialog is then given to confirm the version number. Notice how automatically the build number of my “major.minor.build.revision” version number is incremented.
![]()
Exporting a patch is pretty much the same process as exporting a solution. As is importing them, expect they need to be imported in order. As it is not possible to import a patch with a lower version number than currently deployed.
At some point you will want to roll the patches up to me able to create a new major / minor version of a project. To do this you use the “Clone Solution” option. You can see below that I have selected the “Clone Solution” option from my patched solution.
![]()
It will allow the creation of a new solution with an incremented major/minor version number. (Notice below now the version number updates.) When this new solution is created the patches will no longer be seen in the list of solutions. The new solution with the incremented version can then be exported.
![]()
After I import the new solution as an upgrade the previous patch versions will all be rolled up and I will be left with one final solution.
This might sound complicated but if you test patches you will find the process is actually pretty straight forward. I do recommend that part of your revision include creating solutions and repeatedly applying upgrades and patches to observe the behavior.
It is possible to delete and uninstall a managed parent solution. Doing so will uninstall the patches to the parent solution in reverse order. It is also possible to delete / uninstall an individual managed patch.
It is also possible to delete an unmanaged patch. But this will be simply removing the patch not the underlying changes to components.
To repeat:
It is not advised that unmanaged patches be applied to or removed from a production environment.
Solution Layers
A note about solution layering may be useful! Because if we import multiple managed and unmanaged solutions we may need to understand what the final import on the user experience will be.
Managed and unmanaged solutions can “interact” with the underlying system solution. As these are imported layers of solutions will be created. Meaning you may need to understand how one solution “interacts” with another to create the final application behavior that will be observed by your end users.
The diagram below depicts this concept!
![]()
The system solution (shown in red) this represents the default application behavior.
Managed solutions are installed on top of the system solution. They can modify components found in the system solution or can include new components. Managed solutions can be layered on top of each other, as long as the managed solution enabled customization of its components.
Unmanaged solutions sit above managed solutions. (Don’t forget you create a managed solution by exporting an unmanaged solution.)
I suggest you study the diagram above in detail to appreciate the relationships between these layers of managed and unmanaged solutions. The top level (in yellow) represents the components the users will actually observe. I hope you can see that when a component is in all layers the one to be seen by a user will be from the top level.
As always please include plenty of hands-on time in your preparation! I suggest you create various combinations of unmanaged and manages solutions. And don’t forget to try upgrading them. Hopefully this post has given you multiple pointers for the MB 200 certification.
.
