Solution Framework Fundamentals

A good understanding of the solution framework and its capabilities is required to implement a robust application lifecycle management process. This section is meant as an overview of the solution framework for those who do not have a solid understanding or as a reminder for those solution experts.

What is a Solution?

In its most simplistic form, a solution is a container of application components. A solution is an easy way to group components and move them between environments.

Solutions can be used to ensure all new components have a universal naming prefix and is the method to author, package, maintain and deliver functional configuration and custom code that extends the behaviour of Power Platform.

A solution may comprise of many components which can be categorised broadly into four areas, as shown in the diagram below:

 Solutions come in several different flavours, the primary being managed or unmanaged.

Managed vs Unmanaged Solutions

The introduction of solutions in Version 5.0 sparked significant discussion within the community in terms of whether to use managed or unmanaged solutions. Several characteristics of managed solutions had not been fully established, which often led to misappropriates use of unmanaged solutions.

Managed solutions were often perceived to cause problems. Unintended dependency issues sometimes made them challenging to remove, and the order of import could influence the application behaviour presented to the user if not reliably managed. In the current Dynamics landscape, managed solutions have matured and are the recommended approach for any downstream systems.

There are essential differences between unmanaged and managed solutions which requires a good understanding of how layers are created and intermingle with one another. The variations between the two types of solutions are summarised in the table below:

Solution Layering

As it is possible to import multiple solutions into a single instance, be it all managed, all unmanaged or a mixture of both results in the concept of solution layering. What is solution layering though?

Layering happens on import of solutions when a particular component is affected by change within one or more solutions. Layers define the dependency chain of a component from the initial solution introducing it, through each solution that extends or changes the component’s behaviour. Layers are created through extending components (taking a dependency on it). Layering will always occur when changes are made to any out of the box components.

Layers should be considered on a per-component basis. Although typically drawn as above to express the effect of a solution on another solution, this is always at a component or sub-component level.

For each managed component imported into the environment, there is no unmanaged layer when it is introduced. Unmanaged customisations only exist when a customizer amends the component directly in the instance where the managed solution resides.

Layering Managed Solutions

Managed solutions create layers on a per-component basis, they can also develop on and take dependencies from other managed solutions. Both the import order and the dependencies between managed solutions will influence the layering order of the managed solutions. This is particularly important to appreciate when two or more managed solutions with no interdependencies contain a reference to an out of the box component. In such circumstances, the import order may change the layering order, possibly leading to unintentional application behaviour.

Layering Unmanaged Solutions

Unmanaged solutions do not create any layers. They are just containers to group unmanaged component customisations logically and when imported, will add the contained unmanaged component customisations to the unmanaged layer. Importantly, unmanaged component customisations override any equivalent managed component customisation introduced by managed solutions that lay beneath them.

Once unmanaged component customisations have been introduced to the system, there is no method to delete them.

Solution Segmentation

Solution segmentation was only introduced in version 8.0 but is a very welcome addition to the framework. It provides far more granular control on which components and attributes that you include within your solutions.

Should I add all Assets?

With the segmentation functionality, you can add all assets for a component or individually select only the required assets.

When selected all elements and attributes are added to the solution. This means that for example, you are only adding a single field to the entity that the whole entity with all its attributes will import into your next environment creating layering.

As you can see, when selected, all the attributes of the entity are added to the solution.

If however, you leave it unticked you can add individual components that you wish to change or modify there for reducing the effects of layering and dependencies.

By adding only the sub-components to the solution, the only layering that will happen by importing this solution will be on the account name attribute rather than the full account entity.

When you compare the difference between both options, you can see that the size and complexity of the solution are far reduced by only adding the components that you require.

What about Metadata?

Including entity, metadata adds content to the customizations.xml on the export of the solution. This metadata will be essential to include if there have been any changes that need to be applied to the target environment when installed (such as enable audit or enable mobile for the entity). Conversely, if downstream environments follow stringent configuration control, it is wise to avoid including the entity metadata unless a specific change is required. This can help to prevent accidental changes in behaviour (e.g. audit becoming disabled for the entity).

When should I deploy Metadata?

• Deploying a new entity (enforced)
• Amending an entity’s behaviour – for example, availability on mobile or enabling auditing.

Takeaways

• Include only the assets/sub-assets that have changed – not the entire entity.
  • This reduces the size and complication of the solution imported.
  • Reduces Solution import time.
  • Reduces the code base stored in your source control.
  • Reduces collisions caused by multiple team members working on assets of a component such as an entity.
  • Do not click the add all assets button when adding existing entities to your solution unless you are changing metadata attributes.
• Always use a managed solution in any downstream environments.