Managed vs. Unmanaged Solutions in Power Apps/Dynamics 365

When you’re building solutions in Power Apps or Dynamics 365, you’ll constantly hear about “managed” and “unmanaged” solutions. Understanding the difference between them is important for effective development, deployment, and maintenance. Many developers, especially those new to the Power Platform or Dynamics 365 can find these concepts a bit confusing. Let’s break it down in a clear, step-by-step way.

The Core Problem: How to Move Your Work Safely

Imagine you’re building a new feature maybe a custom form, a workflow, or a special button. You develop it in a “development” environment. Once it’s ready, you need to move it to a “testing” environment for quality checks, and then eventually to your “live” or “production” environment for users to enjoy. How do you ensure that your changes move smoothly, don’t break anything existing, and can be easily managed or even removed later? This is where solutions, and specifically managed versus unmanaged solutions, come into play.

Unmanaged Solutions: Your Sandbox Environment

Think of an unmanaged solution as your personal development sandbox. When you create or customize components directly within an environment, those changes are stored in an unmanaged layer.

Where to Use Them

Development Environments (Dev): Unmanaged solutions are primarily used in your development environments. This is where you create, modify, and test your customizations iteratively. You have full control and can change anything.

Key Characteristics

Editable: Components within an unmanaged solution can be directly edited, modified, or deleted within the environment where the solution is imported.
Source of Truth: Your unmanaged solutions should be considered the “source code” for your Power Platform customizations. It’s a best practice to connect your development environment to a version control system (like Git) to track changes to your unmanaged solution components.
Deletion Behavior: If you delete an unmanaged solution from an environment, only the “container” (the solution itself) is removed. The actual components (like custom fields, forms, etc.) that were part of that solution will remain in the environment and become part of the “Default Solution” or the base system. This can lead to “orphan” components and make cleanup difficult.

Example: Creating a New Field

Let’s say you’re adding a new field to the Account table to store “Customer Loyalty Score.”

Go to your Development Environment.
Open Solutions.
Create a New solution (e.g., “MyCompany_SalesApp”). Set a publisher with a unique prefix (e.g., myco_).
Add the existing account table to your solution.
In the account table, create a new column, let’s say myco_customer_loyalty_score (Type: Whole Number).
Add this new column to the Account main form.
Save and publish your changes.

These changes are now part of your unmanaged solution in your development environment.

Managed Solutions: Your Packaged Product

A managed solution is like a sealed, finished product. Once imported into an environment, its components are “managed,” meaning they are locked down and cannot be directly modified or deleted from that environment’s user interface.

Where to Use Them

Testing Environments (Test, UAT, SIT): These environments should always receive managed solutions. This ensures that what you’re testing is exactly what will be deployed to production, with no unintended local changes.
Production Environments (Prod): Production environments should exclusively use managed solutions. This provides stability, prevents accidental modifications, and allows for clean uninstallation if needed.
Distributing to Customers: If you’re an independent software vendor (ISV) or a consultant delivering solutions to clients, you will distribute your solutions as managed solutions.

Key Characteristics

Immutable (Mostly): Components imported as part of a managed solution generally cannot be edited or deleted directly. This prevents accidental changes and ensures the integrity of your deployed solution. You can, however, sometimes add unmanaged customizations on top of managed components, which creates a new layer (more on layers below).
Clean Uninstallation: When you uninstall a managed solution, all the components introduced by that solution are removed from the environment. This makes cleanup and rollback much easier.
Layered Architecture: Managed solutions operate in layers. When multiple solutions modify the same component, they stack on top of each other, with the last installed solution “winning” (its changes take precedence). This is crucial for understanding how customizations behave.
No Export: You cannot export a managed solution from an environment once it’s been imported. You must always export managed solutions from the original unmanaged solution in the development environment.

Exporting as Managed

Once your unmanaged solution is complete and thoroughly tested in development, you export it as a managed solution for deployment.

In your Development Environment.
Go to Solutions.
Select your Unmanaged Solution (e.g., “MyCompany_SalesApp”).
Click Export solution.
Choose Managed as the package type.
Follow the prompts to export the solution. This will generate a .zip file.

Importing as Managed

Now, you take this .zip file and import it into your target environment (Test, UAT, Prod).

Go to your Target Environment (e.g., Test).
Open Solutions.
Click Import solution.
Browse for your exported managed solution .zip file and import it.

After importing, try to edit the myco_customer_loyalty_score field in the Account table within the Test environment’s Solution Explorer. You’ll notice it’s locked and cannot be changed directly.

Solution Layers: Understanding Precedence

Solution layers are a fundamental concept to grasp. Every customization in Power Apps/Dynamics 365 exists within a layer. When you make changes, new layers are added. The system combines these layers to determine the final behavior of a component.

The Order of Layers (from bottom to top/lowest precedence to highest precedence):

System Layer: The base definition of all out-of-the-box (OOB) components provided by Microsoft.
Managed Layers: Each managed solution you import creates its own layer. The order of these layers depends on the order of import, newer managed solutions are “on top” of older ones.
Unmanaged Layer: This is the top layer. Any unmanaged customizations (either from imported unmanaged solutions or direct customizations made in the environment) reside here. This means unmanaged changes always “win” over managed changes if they conflict.

Example Scenario with Solution Layers

Imagine you have an Account table with a Description field.

Scenario 1: Base System. The Description field has a maximum length of 2000 characters (System Layer).
Scenario 2: Managed Solution 1. You import a managed solution that changes the Description field’s max length to 1000 characters. This creates a managed layer on top of the System Layer. The effective max length is now 1000.
Scenario 3: Managed Solution 2 (later). You import another managed solution (from a different vendor or internal project) that changes the Description field’s max length to 500 characters. This creates a new managed layer on top of Managed Solution 1’s layer. The effective max length is now 500.
Scenario 4: Unmanaged Customization. In the same environment, you directly open the Description field and change its max length to 1500 characters. This creates an unmanaged layer on top of all managed layers. The effective max length is now 1500.

Viewing Solution Layers: You can inspect solution layers for any component (like a field, form, or view) in the Power Apps Maker Portal by navigating to the component, clicking “…” (More commands) or “Advanced,” and then “See solution layers.” This is incredibly useful for troubleshooting!

Best Practices for Solution Components

Choosing how to structure your solutions is key to a maintainable Power Platform environment.

Strategy 1: One Big Solution

Concept: Put all your customizations for a single application or project into one large unmanaged solution in your development environment.
Pros:
- Simpler to manage initially, as everything is in one place.
- Easier to track related components.
Cons:
- Can become unwieldy for large, complex projects.
- Deployment takes longer as you’re deploying everything every time.
- Higher risk of conflicts if multiple teams work on different parts of the same solution.
- If you need to update a small part, you still deploy the entire large solution.

Strategy 2: Split Solutions (Modular Approach)

Concept: Break down your customizations into smaller, more focused unmanaged solutions based on functional areas, component types, or teams.
Pros:
- Modular Deployment: You can deploy smaller, independent updates. For example, if only a workflow changes, you deploy only the workflow solution.
- Reduced Conflicts: Less chance of different teams or developers accidentally overwriting each other’s work if they are working in separate functional solutions.
- Easier Maintenance: Smaller solutions are easier to understand, troubleshoot, and maintain.
- Improved ALM: Aligns better with advanced Application Lifecycle Management (ALM) practices.
Cons:
- Requires more initial planning and discipline to manage dependencies between solutions.
- Might lead to more solutions to track overall.

Recommended Approach: Modular Solutions with Core Data Model

For most professional Dynamics 365/Power Apps development, a modular approach is strongly recommended.

Core Data Model Solution: Create a “base” unmanaged solution that contains your core Dataverse tables (entities), columns (fields), and relationships that are fundamental to your application. This solution should be deployed first as a managed solution to your downstream environments.
Functional/Component-Specific Solutions: Create separate unmanaged solutions for specific functionalities or component types. Examples:
- MyCompany_SalesWorkflows (contains Power Automate flows, classic workflows)
- MyCompany_SalesForms (contains custom forms, views, charts for sales entities)
- MyCompany_SecurityRoles (contains custom security roles)
- MyCompany_CanvasApps (contains canvas apps)
- MyCompany_Plugins (contains custom plugin assemblies and steps)

Tips for Solution Component Strategy:

One Publisher: Always use a single, consistent publisher for all your solutions within an organization or project. This makes tracking and managing solutions much easier. The publisher prefix (e.g., myco_) ensures uniqueness for your custom components.
Segmented Components: Don’t put the same component (like a field or table) into multiple independent unmanaged solutions that you plan to deploy as managed. This can lead to complex dependency issues and make uninstallation or updates problematic. For example, if myco_customer_loyalty_score is in MyCompany_SalesApp, don’t also add it to MyCompany_CustomerService. If a component needs to be shared, it should ideally reside in a common “base” or “core” solution.
Dependencies: When you export a solution, Power Apps will often prompt you to include required components. Be cautious and only include what is genuinely needed. Manually adding specific components to your solution often gives you better control.
Version Control: Always store your unmanaged solution .zip files (or ideally, extract their contents into source control) in a version control system like Azure DevOps Git or GitHub. This is your safety net for tracking changes, reverting to previous versions, and collaborating.

When you’re building solutions in Power Apps or Dynamics 365, you’ll constantly hear about “managed” and “unmanaged” solutions. Understanding the difference between them is crucial for effective development, deployment, and maintenance. Many developers, especially those new to the Power Platform or those whose first language isn’t English, can find these concepts a bit confusing. Let’s break it down in a clear, step-by-step way, avoiding unnecessary jargon.

The Core Problem: How to Move Your Work Safely

Imagine you’re building a new feature – maybe a custom form, a workflow, or a special button. You develop it in a “development” environment. Once it’s ready, you need to move it to a “testing” environment for quality checks, and then eventually to your “live” or “production” environment for users to enjoy. How do you ensure that your changes move smoothly, don’t break anything existing, and can be easily managed or even removed later? This is where solutions, and specifically managed versus unmanaged solutions, come into play.

Unmanaged Solutions: Your Workshop Environment

Think of an unmanaged solution as your personal development sandbox. When you create or customize components directly within an environment, those changes are stored in an unmanaged layer.

Where to Use Them

Development Environments (Dev): Unmanaged solutions are primarily used in your development environments. This is where you create, modify, and test your customizations iteratively. You have full control and can change anything.

Key Characteristics

Editable: Components within an unmanaged solution can be directly edited, modified, or deleted within the environment where the solution is imported.
Source of Truth: Your unmanaged solutions should be considered the “source code” for your Power Platform customizations. It’s a best practice to connect your development environment to a version control system (like Git) to track changes to your unmanaged solution components.
Deletion Behavior: If you delete an unmanaged solution from an environment, only the “container” (the solution itself) is removed. The actual components (like custom fields, forms, etc.) that were part of that solution will remain in the environment and become part of the “Default Solution” or the base system. This can lead to “orphan” components and make cleanup difficult.

Example: Creating a New Field

Let’s say you’re adding a new field to the Account table to store “Customer Loyalty Score.”

Go to your Development Environment.
Open Solutions.
Create a New solution (e.g., “MyCompany_SalesApp”). Set a publisher with a unique prefix (e.g., myco_).
Add the existing account table to your solution.
In the account table, create a new column, let’s say myco_customer_loyalty_score (Type: Whole Number).
Add this new column to the Account main form.
Save and publish your changes.

These changes are now part of your unmanaged solution in your development environment.

Managed Solutions: Your Packaged Product

A managed solution is like a sealed, finished product. Once imported into an environment, its components are “managed,” meaning they are locked down and cannot be directly modified or deleted from that environment’s user interface.

Where to Use Them

Testing Environments (Test, UAT, SIT): These environments should always receive managed solutions. This ensures that what you’re testing is exactly what will be deployed to production, with no unintended local changes.
Production Environments (Prod): Production environments should exclusively use managed solutions. This provides stability, prevents accidental modifications, and allows for clean uninstallation if needed.
Distributing to Customers: If you’re an independent software vendor (ISV) or a consultant delivering solutions to clients, you will distribute your solutions as managed solutions.

Key Characteristics

Immutable (Mostly): Components imported as part of a managed solution generally cannot be edited or deleted directly. This prevents accidental changes and ensures the integrity of your deployed solution. You can, however, sometimes add unmanaged customizations on top of managed components, which creates a new layer (more on layers below).
Clean Uninstallation: When you uninstall a managed solution, all the components introduced by that solution are removed from the environment. This makes cleanup and rollback much easier.
Layered Architecture: Managed solutions operate in layers. When multiple solutions modify the same component, they stack on top of each other, with the last installed solution “winning” (its changes take precedence). This is crucial for understanding how customizations behave.
No Export: You cannot export a managed solution from an environment once it’s been imported. You must always export managed solutions from the original unmanaged solution in the development environment.

Exporting as Managed

Once your unmanaged solution is complete and thoroughly tested in development, you export it as a managed solution for deployment.

In your Development Environment.
Go to Solutions.
Select your Unmanaged Solution (e.g., “MyCompany_SalesApp”).
Click Export solution.
Choose Managed as the package type.
Follow the prompts to export the solution. This will generate a .zip file.

Importing as Managed

Now, you take this .zip file and import it into your target environment (Test, UAT, Prod).

Go to your Target Environment (e.g., Test).
Open Solutions.
Click Import solution.
Browse for your exported managed solution .zip file and import it.

Solution Layers: Understanding Precedence

The Order of Layers (from bottom to top/lowest precedence to highest precedence):

System Layer: The base definition of all out-of-the-box (OOB) components provided by Microsoft.
Managed Layers: Each managed solution you import creates its own layer. The order of these layers depends on the order of import – newer managed solutions are “on top” of older ones.
Unmanaged Layer: This is the top layer. Any unmanaged customizations (either from imported unmanaged solutions or direct customizations made in the environment) reside here. This means unmanaged changes always “win” over managed changes if they conflict.

Example Scenario with Solution Layers

Imagine you have an Account table with a Description field.

Scenario 1: Base System. The Description field has a maximum length of 2000 characters (System Layer).
Scenario 2: Managed Solution 1. You import a managed solution that changes the Description field’s max length to 1000 characters. This creates a managed layer on top of the System Layer. The effective max length is now 1000.
Scenario 3: Managed Solution 2 (later). You import another managed solution (from a different vendor or internal project) that changes the Description field’s max length to 500 characters. This creates a new managed layer on top of Managed Solution 1’s layer. The effective max length is now 500.
Scenario 4: Unmanaged Customization. In the same environment, you directly open the Description field and change its max length to 1500 characters. This creates an unmanaged layer on top of all managed layers. The effective max length is now 1500.

Best Practices for Solution Components

Choosing how to structure your solutions is key to a maintainable Power Platform environment.

Strategy 1: One Big Solution

Concept: Put all your customizations for a single application or project into one large unmanaged solution in your development environment.
Pros:
- Simpler to manage initially, as everything is in one place.
- Easier to track related components.
Cons:
- Can become unwieldy for large, complex projects.
- Deployment takes longer as you’re deploying everything every time.
- Higher risk of conflicts if multiple teams work on different parts of the same solution.
- If you need to update a small part, you still deploy the entire large solution.

Strategy 2: Split Solutions (Modular Approach)

Concept: Break down your customizations into smaller, more focused unmanaged solutions based on functional areas, component types, or teams.
Pros:
- Modular Deployment: You can deploy smaller, independent updates. For example, if only a workflow changes, you deploy only the workflow solution.
- Reduced Conflicts: Less chance of different teams or developers accidentally overwriting each other’s work if they are working in separate functional solutions.
- Easier Maintenance: Smaller solutions are easier to understand, troubleshoot, and maintain.
- Improved ALM: Aligns better with advanced Application Lifecycle Management (ALM) practices.
Cons:
- Requires more initial planning and discipline to manage dependencies between solutions.
- Might lead to more solutions to track overall.

Recommended Approach: Modular Solutions with Core Data Model

For most professional Dynamics 365/Power Apps development, a modular approach is strongly recommended.

Core Data Model Solution: Create a “base” unmanaged solution that contains your core Dataverse tables (entities), columns (fields), and relationships that are fundamental to your application. This solution should be deployed first as a managed solution to your downstream environments.
Functional/Component-Specific Solutions: Create separate unmanaged solutions for specific functionalities or component types. Examples:
- MyCompany_SalesWorkflows (contains Power Automate flows, classic workflows)
- MyCompany_SalesForms (contains custom forms, views, charts for sales entities)
- MyCompany_SecurityRoles (contains custom security roles)
- MyCompany_CanvasApps (contains canvas apps)
- MyCompany_Plugins (contains custom plugin assemblies and steps)

Tips for Solution Component Strategy:

One Publisher: Always use a single, consistent publisher for all your solutions within an organization or project. This makes tracking and managing solutions much easier. The publisher prefix (e.g., myco_) ensures uniqueness for your custom components.
Segmented Components: Don’t put the same component (like a field or table) into multiple independent unmanaged solutions that you plan to deploy as managed. This can lead to complex dependency issues and make uninstallation or updates problematic. For example, if myco_customer_loyalty_score is in MyCompany_SalesApp, don’t also add it to MyCompany_CustomerService. If a component needs to be shared, it should ideally reside in a common “base” or “core” solution.
Dependencies: When you export a solution, Power Apps will often prompt you to include required components. Be cautious and only include what is genuinely needed. Manually adding specific components to your solution often gives you better control.
Version Control: Always store your unmanaged solution .zip files (or ideally, extract their contents into source control) in a version control system like Azure DevOps Git or GitHub. This is your safety net for tracking changes, reverting to previous versions, and collaborating.
Patching and Upgrades: For minor bug fixes or small enhancements to a managed solution, consider using solution patches. For larger feature releases, use solution upgrades. Understand the difference and how they interact with solution layers.

Code Example (Plugin Registration – Conceptual)

When you register a plugin in your development environment, you associate it with your unmanaged solution. For example, if you have a plugin that runs on the account table’s create message:

// Example Plugin Code (C#)
namespace MyCompany.Plugins
{
    public class PostCreateAccount : IPlugin
    {
        public void Execute(IServiceProvider serviceProvider)
        {
            ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
            IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
            IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
            IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

            if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity targetEntity)
            {
                if (targetEntity.LogicalName == "account")
                {
                    // Your plugin logic here, e.g., set the loyalty score
                    if (targetEntity.Contains("myco_customer_loyalty_score") == false)
                    {
                        targetEntity["myco_customer_loyalty_score"] = 10; // Default score
                    }
                    service.Update(targetEntity); // Not typically done in Post-Operation, but for demonstration
                }
            }
        }
    }
}

This plugin assembly and its steps would be added to your MyCompany_SalesApp unmanaged solution. When you export this solution as managed and import it into a test or production environment, the plugin will be deployed along with it and will be part of the managed layer.

Takeaway

Understanding the distinction between managed and unmanaged solutions is fundamental for any Power Apps or Dynamics 365 professional.

Unmanaged Solutions are for development environments, offering full flexibility and editability. They are your source code and should be version controlled.
Managed Solutions are for testing and production environments, providing stability, control, and clean uninstallation. They are the deployable packages of your finalized customizations.
Solution Layers determine the effective behavior of components, with unmanaged customizations always taking precedence over managed ones.
Best Practice: Adopt a modular solution strategy with a clear separation of concerns (e.g., core data model, functional solutions) and always use managed solutions for deployment to non-development environments. This ensures a robust, scalable, and maintainable Power Platform implementation.