Introduction
In the previous post, I explained immutability and the two layers of storing components. We now know the importance of immutability, but we haven’t learned how to manage it. We learned that using an unmanaged solution is against immutability.
What if we move our component to the managed layer aligned with immutability?
The answer is that you need a managed solution. However, you should know that the only way to create a managed solution is from an unmanaged solution. Moving to the unmanaged and managed layers originates from unmanaged solutions. Therefore, in this post, I want to delve deeper into the properties and characteristics of unmanaged solutions. Some of them are important for the unmanaged solution, and some will affect the managed solution.
Unmanaged solutions
Do you remember this from part 3 of the series:
At the end of the second blog, we understood why working in a production environment is terrible. Then, in part 3, I showed you a good practice of moving components via unmanaged solutions to provide a development environment. Although we made them in production, we didn’t want to lose our work. So, we exported our solution as unmanaged, and then, by importing it, we brought it to the Development environment.
Solution type is something you choose when exporting a solution. As the following picture shows:
But wait a moment! Can we create a managed solution in the same way we make an unmanaged solution?
No, you can’t. The following picture shows the creation of a solution.
As you see, its package type is, by default, Unmanaged, and you cannot change it. As the information button shows, you can only create the managed solution by exporting it.
Solution properties
When you create a solution, Display name, Name, publisher, and version are mandatory.
The Display Name is the most minor in ALM. You can always change it, and it won’t have any technical effect on anything. You need to keep it consistent for the sake of documentation. It is just used to display the solution’s name.
Version does not affect the unmanaged solution because you can change it even after importing it to another environment. So, we investigate it when delving into managed solutions.
However, the Name is very important because it is the identity of the solution, and you can’t change it after you create it. It also plays a role in your solution’s unique identity when you move it to managed and unmanaged environments.
Publisher
Publishers are a particular type of component. They can reside in an unmanaged or managed layer. When you create your solution, you can either choose an existing publisher from the unmanaged layer or create a new one (again, on the unmanaged layer). You can’t select a publisher that resides in the managed layer.
The publisher plays two different roles depending on the type of solution.
1) Role of Publisher for unmanaged solutions:
When creating components inside an unmanaged solution, if their names need prefixes, they come from the publisher. For example, when you create a Table or a Column, their names will have the same prefix as the solution publisher’s. Also, choice values, whether global or single, are prefixed with the value defined by the publisher, and good practice is to keep the default choice value that the system selects for your publisher.
This is the only publisher usage for unmanaged solutions, the component name prefix, and the choice value prefix.
2) Role of Publisher for Managed Solutions:
However, when it comes to managed solutions, the publisher acts as the owner of a component. This ownership is hidden. So, please do not confuse it with the ownership of your apps or flows. This ownership relates to the deployment and becomes essential when considering multiple solutions. However, it is outside our current example’s concern. We will delve into this when investigating advanced scenarios.
Usages of unmanaged solutions
So far, we have learned two usages of unmanaged solutions:
- Creating or Editing components
- Moving components
The third usage is for moving the publisher as unmanaged. This is used in advanced scenarios when we have multiple development environments and want to use the same publisher for our solutions. For our scenario, where we use only one development environment, we don’t need it.
So that you know, you can create an empty solution (without any components) and choose the publisher you want to move. You will have the same publisher in the unmanaged layer by importing your unmanaged solution into another environment.
So, to summarize, good practice for using unmanaged solutions is:
When working inside a development environment, doing it inside your unmanaged solution is always recommended. There are two reasons for that:
1. You ensure your new components use the correct prefixes.
2. When you want to export it as a managed solution and deploy it to downstream environments, you already have your components inside your solution and don’t need to look for them.
Another good practice is using unmanaged solutions to provide a new development environment if needed.
With that said, bad practice is to deploy your components to UAT or production with an unmanaged solution.
Default solution
As its name implies, the default solution is a particular solution created by default when you create any environment. It includes all components inside your environment and resides in the unmanaged layer. All components inside the environment are automatically added to the Default solution. It is just a place to find the component you are looking for, especially when you don’t remember which solution you put your component in.
This solution’s unique feature is that you can’t delete or export it. However, it inherits the editing feature of unmanaged solutions. You can open a component inside it and start editing. You can also create a new component inside a default solution, which is a bad practice. As I said before, good practice is to create your components inside a solution for which you have chosen the proper publisher. That way, your component will get its name or choice value prefixes from the correct publisher.
Deleting unmanaged solution
Unmanaged solutions other than the default solution can be deleted. An unmanaged solution plays the role of a container. After the component is created, which is affected by its solution publisher, there is no dependency between the containing components and its solution. This means you can delete an unmanaged solution, and all the components inside it will still exist in that environment.
Those components can still be found inside the default solution, and you can create a new solution and add them to it.
Conclusion
ALM is a practice with a maturity model matrix. As you might consider, I have started from the lowest level to make the foundation for the following levels. Solution is a crucial part of ALM, and its types have always confused newcomers to the Power Platform or Dynamics 365 customer engagement world.
You have learned the characteristics of unmanaged solutions, which is also the origin of managed solutions. In the next post, I will delve into managed solutions.