1. Working with solutions (this post)
2. Working with tables
3. Working with forms
4. Working with views
5. Working with the App Designer

UPDATE: If you prefer to follow along in a YouTube video instead you can find it here:
Getting Start With Model-Driven Apps – Working with Solutions

In this post I will present the most important aspects of solutions that you need to be familiar with, when working with model-driven apps. Even though my focus is mainly on model-driven apps, many of the key points in this post also apply to canvas apps, and other objects on the power platform in general.

For every problem, there is a Solution

The Power Platform empowers organizations to create low-code/no-code tailored business applications and streamline their processes effectively. At the heart of this platform are the “solutions”, which serve as containers for organizing, managing, and deploying customizations.

In this post I am going to cover the 5 key areas that I think are most important to know about when working with solutions:

1) What are solutions
2) Managed and unmanaged layers
3) Best practice when working with solutions
4) Possible pitfalls
5) Key differences between working solutions and the app designer

1. What are solutions?

So what is a solution? A solution can be seen as the Power Platform framework for dealing with two distinct requirements when developing apps.

1: The first is the need to have a clear repository of what is being developed (this can be either by a specific person, company, or for a specific change request/issue/etc.).

2: The second is to manage the transfer of any modifications or customizations between environments – typically from the development environment, over to the test environment, and finally on to the production environment.

In this way, Solutions act as containers for customizations such as entities, fields, views, forms, workflows, and other objects. They allow users to package and distribute applications, business processes, or specific functionalities as manageable units. Solutions can be exported, imported, and shared across environments, providing a flexible and scalable approach to application development and deployment.

By doing this, they also provide an easy overview of what is being worked on either by a specific person or team, for a specific application or even for a specific function (the granularity of this can be determined based on your organizational needs). As mentioned above, you should adhere to a best-practice of using solutions to only contain what is being added or modified.

2. Managed and unmanaged layers

When working with solutions, it is imperative to understand the key differences between managed and unmanaged solutions, and the consequence of how each are used. I will first explain what the two terms mean, and then provide an example of what happens when solutions layers are applied.

Unmanaged Solutions
Unmanaged solutions are primarily used during the development phase. They allow direct customization of components within the solution, providing a highly flexible and iterative approach. With unmanaged solutions, changes made in one environment can be easily merged into another environment. However, caution must be exercised when using unmanaged solutions, as they offer fewer restrictions and can lead to unintended consequences if not managed properly.

Managed Solutions
Managed solutions are typically used for distribution and deployment in production environments. They provide a locked-down, packaged experience, ensuring that customizations within the solution cannot be modified directly in the target environment. Managed solutions offer a controlled environment where customizations are only allowed through the solution publisher, ensuring better governance, versioning, and control over the application lifecycle.

So what does this mean for me as a Power Platform citizen developer?
The dotted line on the left side represent the solution layer filtering. Everything goes from bottom to the top, and the top layer is always “right”. So irregardless of how many time an object has been altered throughout this filtering, the change made in the top layer will determine what actually happens in the application layer and what the end-user will see.

A concrete example of this could be the “full name” column in the user table. In the standard Dataverse system layer, the user table has the full name column as the primary name column, but there could be a managed solution where this column was renamed to just be “Name” instead. Then in the unmanaged layer it could be renamed to “Real name”.
The end result is that the application (including views) would see “Real name” and not any other of the options, as they are further down in the solution layers and therefore not relevant anymore.

For this reason it is also important to never have unmanaged layers on any other environments than the development environment, as unmanaged layers do not give you any control over the specific objects, nor the ability to roll back changes made. I will make a longer post at a later point diving in to solution management between environments.

3. Best Practices

• Plan Ahead: Clearly define the scope and objectives of your solution before starting development to ensure a streamlined implementation.
• Version Control: Maintain proper versioning of your solutions to track changes, rollback if necessary, and ensure smooth collaboration among team members.
• Solution Layering: Organize your customizations into multiple layers within a solution, separating base components from customizations, and allowing easier maintenance and upgrades.
• Documentation: Document your solution design, configurations, and dependencies to aid in troubleshooting, future enhancements, and knowledge sharing.
• Solution Lifecycle Management: Follow a structured approach for solution deployment, testing, and promotion between environments using tools like Azure DevOps or Power Platform Build Tools.

4. Possible pitfalls

There are several things that you need to consider when working with solutions. These are a couple of examples of possible pitfalls:

• Over-customization: Solutions can become complex if not planned properly, leading to performance issues, conflicts, and difficulty in maintaining and upgrading the solution.
• Dependency Conflicts: Be cautious when managing dependencies between solutions, as changes made to one solution may impact others.
• Solution Mismatch: Avoid deploying a solution to an environment where its dependencies or prerequisites are not met, as this can cause errors or unexpected behavior.
• Data Loss: Exercise caution when uninstalling or removing managed solutions, as it may result in the loss of data associated with those customizations.

5. Key differences between working solutions and the app designer

Part five of this series will also cover the app designer in more depth, but I wanted to touch upon some key differences between the App Designer and solutions in this post, as this is important to be aware of at an early stage.

The App Designer is a visual tool within the Power Platform that enables users to create model-driven apps. As mentioned already, solutions provide a container for organizing and managing customizations. So the App Designer focuses on the design and configuration of the user interface, business logic, and app-specific functionalities. The App Designer thus allows for rapid application development using a low-code approach, while solutions provide a broader framework for managing the entire solution lifecycle, including customizations, dependencies, and deployment.

Many citizen developers instinctually gravitate towards working with the app designer first as a basis for building their application, which also makes sense from a UI/UX point of view, as this also lets you work with your application in preview-mode and is a graphical approach instead of the “technical” approach of the solution. However, it is important to keep in mind that any changes made in the app designer are not reflected in the solution and therefore, when exporting the solution to a new environment, changes made in the app designer need to be reflected in the solution as well. This is because the app designer itself only provides an overview of which elements are used in the application, whereas the solution only provides the image of what the specific development iteration contains. This can be hard to navigate for new users, as the layers of solutions can become quite complex.

An example could be adding a table and making modifications to it in an application. Even if the table is a standard CDS table, any modifications made to any objects in the table also needs to be added to the solution itself, or they will not work correctly when running the application on the test and production environments.

Wrapping up
Solutions play a crucial role in harnessing the full potential of the Power Platform by providing a structured approach to organizing and deploying customizations. By understanding the concepts of managed and unmanaged layers, as well as avoiding the pitfalls of working with solutions, you are well on your way to becoming a successful citizen developer!