Solutions

8 minutes

Solutions are containers that track and manage customizations in a Dataverse environment. Solutions are used to transport apps and components from one environment to another or to apply a set of customizations to existing apps.

When you have multiple environments, each environment has its own set of solutions.

Diagram that shows the Solution overview environment.

Note

When you have a Microsoft Dynamics 365 app, such as Sales, the app is installed by using the same solution framework. ISVs also ship their products by using solutions.

The characteristics of solutions are that they:

Include metadata and certain entities with configuration data. Solutions don't contain business data.
Contain many different Microsoft Power Platform components, such as model-driven apps, canvas apps, site maps, flows, tables, table metadata, columns, forms, views, business rules, process definitions, custom connectors, web resources, choices, charts, and components that are created by developers such as scripts or compiled code.
Are packaged as a unit to be exported and imported to other environments, or they're deconstructed and checked into source control as source code for assets.
Are used to apply changes to existing solutions.

Types of solutions

Two types of solutions are:

Unmanaged - Used during development and to transport to other development environments.
Managed - Used to distribute to nondevelopment environments.

You would use unmanaged solutions in development environments while you're making configuration changes to your application. Solutions are exported as unmanaged and are then checked into your source control system. Unmanaged solutions should be considered your source.

Use managed solutions to deploy to any environment that isn't a development environment, including test, user acceptance testing (UAT), system integration testing (SIT), and production environments.

Managed solutions can be serviced (upgrade, patch, and delete) independently from other managed solutions. As an ALM best practice, managed solutions should be generated by a build server and considered a build artifact.

Solution layering

Solution layers describe the dependency chain of a component from the root solution that introduces it, through each solution that extends or changes the component’s behavior. Layers are created through extension of an existing component (taking a dependency on it) or through creation of a new component or version of a solution.

Solution layering is implemented at a component level. Managed and unmanaged solutions exist at different layers within a Microsoft Dataverse environment. Dataverse has two distinct layers:

Unmanaged layer - All imported, unmanaged solutions and specialized customizations exist at this layer. All unmanaged solutions share a single unmanaged layer.
Managed layer - All imported, managed solutions and the system solution exist at this level. When multiple managed solutions are installed, the last one that is installed is above the managed solution that was previously installed. Therefore, the second solution that is installed can customize the one that was installed before it. When two managed solutions have conflicting definitions, the runtime behavior is "Last one wins" or a merge logic is implemented. If you uninstall a managed solution, the managed solution below it takes effect. If you uninstall all managed solutions, the default behavior that is defined within the system solution is applied. At the base of the managed layers level is the system layer. The system layer contains the entities and components that are required for the platform to function.

Diagram that shows the solution layers.

Solution architects need to decide on the number of solutions that will be used for their business solution. While you could work with a single solution, it would lead to dependencies on releases, and large solutions can take a long time to export and import. Most projects use multiple solutions. Solution architects should understand the merged behavior when a solution is updated or when multiple solutions are installed that affect the same component.

In the following example, we have four solutions using Common Data Model/System tables: Common Data Model Healthcare solution, a Contoso Common solution, and two solutions that contain apps and are layered. For example, let's say we customize the 'Contact' form in the Common Data Model Healthcare extension. Then if we modify the same form elements in the Contoso Common solution, users see the changes from the Contoso Common solution.

Diagram showing example solution layers.

Solution structure

Strategies for creating solutions, listed in order from simplest to most complex, are:

Single solution
Multiple solutions
Multiple solutions with shared components

By creating a single solution, you'll establish a working set of customizations. This approach helps make it easier to find items that you have customized. Additionally, this approach is recommended when you only want to create a single managed solution. If you think that you might have to split up the solution in the future, consider using multiple solutions.

If you have two unrelated solutions that don’t share components, the most direct approach is to create two unmanaged solutions.

You might have multiple solutions that share components. You might have a certain set of common functionalities within multiple solutions, and that common functionality is compatible with any of the other functionalities that are unique to each solution. Some components can be included in more than one solution, if any changes that were made to them are compatible with all other solutions that use them. It's important that all solutions share the same solution publisher. If the solution publisher isn't identical, you won't be able to install more than one of your solutions.

Rules that you should follow with solutions:

Create a solution publisher and use it for all solutions.
Don’t use the default publisher, the default solution, or the Dataverse default solution.
Keep the solution structure as simple as possible.
Avoid selecting the Include all components check box unless you're adding an unmanaged table.
Include table metadata only when you're changing table properties.
Add the subcomponents of a table (columns, forms, views, and so on) only when you're changing them.

Adding only what is required to a solution is known as segmenting a solution.

Screenshot that shows the adding of a table.

When deciding how to segment into one or more solutions, you should consider the following:

Use multiple solutions only for a tangible purpose because multiple solutions add complexity.
Avoid multiple solutions that share components.
Multiple solutions require their own environments to ensure that they remain independent.
Take care to manage dependencies.
Makers must know what solution to put new components in.
Common patterns for multiple solution splittings are horizontal and vertical partitioning.

Horizontal solution splitting

Horizontal splitting refers to creating solutions that only contain components of the same type.

Diagram of horizontal solution splitting.

Vertical solution layering

Vertical layering will group components into functional areas. Often, you'll have a shared base/common solution with separate solutions for each key business area.

Diagram that shows vertical solution layering.