ALM: Solutions and Versioning in Power Platform

Introduction to Solution Management

Solution management represents the core of Application Lifecycle Management (ALM) practices within Microsoft Power Platform. A solution is a container that encapsulates all components — tables, apps, flows, connectors, APIs, and business rules — that form a business application or feature. Its main purpose is to enable consistent deployment of these components across different environments (development, test, production).

To use solutions, the Power Platform environment must include a Microsoft Dataverse database. Without Dataverse, this functionality is unavailable. The solution-based approach is now mandatory for transferring components between environments, ensuring consistency and traceability.

Solution Types: Unmanaged and Managed

Solutions are divided into two main categories, each with distinct characteristics and purposes within the ALM process.

Unmanaged Solutions

• Created manually or through code in the development environment.
• Considered “open,” allowing any setting or component to be modified.
• Can be exported as either unmanaged or managed.
• Deleting an unmanaged solution does not remove components; they remain in the Default Solution.

Unmanaged solutions are ideal during development, where flexibility and iteration are required. However, they should never be deployed to test or production environments.

Managed Solutions

• Created only by exporting an unmanaged solution.
• Considered “closed,” locking some or all components to prevent modification.
• Can be imported but not exported.
• Best suited for downstream environments (testing, staging, production).

Managed solutions ensure integrity and protect intellectual property, especially valuable for ISVs or teams distributing solutions via Microsoft AppSource.

Solution Layering

Layering is a fundamental principle for understanding how customizations are applied in a Power Platform environment. Each component can exist across multiple stacked layers:

• System Layer: contains Dataverse core tables, which cannot be modified.
• Managed Layer: includes all managed solutions imported into the environment. The installation order affects dependencies.
• Unmanaged Layer: hosts open solutions created or imported locally, without inter-solution layering.

Solution dependencies follow a bottom-up behavior: a solution can only depend on components from lower layers. If a dependency is missing, the import will fail.

Dependencies and Segmentation

Each solution may contain components that depend on others, such as tables, columns, or processes. To minimize the negative impact of dependencies and improve modularity, the solution segmentation concept was introduced starting with Dynamics 365 version 8.0.

Segmentation allows including only a subset of table subcomponents within a solution, enabling parallel development by multiple team members and reducing conflicts. It is also the foundation for patching and updating solutions.

Patching and Updating Solutions

With segmentation, Power Platform introduced the concepts of patches and updates to improve incremental change management.

Solution Patch

• Created from an existing unmanaged solution.
• Contains minor changes, typically used for bug fixes or small functional updates.
• Locks the original solution until the patch is exported as managed.

Solution Update

An update represents a new version of the main solution. During import, you can choose between:

• Upgrade: updates and removes obsolete components.
• Stage for upgrade: allows deferred upgrading, temporarily maintaining both versions.
• Update: adds new components without removing old ones (no longer recommended).

Solution Versioning

Each solution must include a numeric version in the format Major.Minor.Build.Revision (for example, 1.0.10.125). This version is crucial for managing patches, upgrades, and compatibility between environments. It is important to distinguish between the Dataverse internal version and the repository-managed version (for example, in Azure DevOps).

Within ALM, tools such as Azure DevOps or GitHub are used to track exported solution versions and maintain source code continuity.

Configuration Pages and HTML Resources

A Configuration Page is an HTML web resource included in the solution package, often used by ISVs to allow administrators to input configuration data, license keys, or initial settings after installation. These pages must implement logic to write configuration data into Dataverse.

HTML, CSS, and JavaScript web resources are solution-aware components directly loaded into Dataverse. They can reference each other, for example:

<link rel="stylesheet" type="text/css" href="../styles/contoso.css" />

Code web resources (JavaScript) can interact with the Dataverse client API, manipulate forms, and communicate with external services.

Microsoft Best Practices for ALM and Versioning

• Use a single publisher for all project solutions.
• Use unmanaged solutions only in development and managed ones in all other environments.
• Follow a strict versioning and consistent naming policy.
• Apply segmentation to minimize conflicts and dependencies.
• Integrate Azure DevOps for automated build, export, and deployment pipelines.

Following Microsoft’s guidance, organizations like Contoso Inc. achieved greater stability and control in multi-environment deployments, improving time-to-market and release quality.