14.1 Unmanaged vs. Managed Solutions & Solution Layering Mechanics

Unmanaged vs. Managed Solutions & Solution Layering Mechanics

In Microsoft Power Platform, Solutions are the fundamental vehicle for implementing Application Lifecycle Management (ALM). Solutions act as packaging containers that encapsulate Dataverse schema (tables, columns, relationships), user interfaces (model-driven apps, canvas apps, custom pages), business logic (cloud flows, business process flows, business rules, plug-ins), security definitions, and configuration metadata. To succeed as a functional consultant and pass the PL-200 exam, you must master the differences between unmanaged and managed solutions, understand how Dataverse calculates runtime behavior across solution layers, and know how to diagnose and resolve customization conflicts across development, test, and production environments.

---

1. Solution Fundamentals: Unmanaged vs. Managed Packages

Every environment in Microsoft Dataverse contains a solution architecture that separates development authoring from production delivery.

+-----------------------------------------------------------------------------------+
|                         POWER PLATFORM SOLUTION PARADIGM                          |
|                                                                                   |
|  [DEVELOPMENT ENVIRONMENT]                       [TEST / PRODUCTION ENVIRONMENT]  |
|  +----------------------------+                  +----------------------------+   |
|  |    UNMANAGED SOLUTION      |  Export Managed  |      MANAGED SOLUTION      |   |
|  | - Authoring container      | ---------------> | - Compiled deployment pack |   |
|  | - Direct edits permitted   |    (CI/CD or     | - Read-only / Locked       |   |
|  | - Loose collection of refs |     Manual)      | - Clean uninstall support  |   |
|  +----------------------------+                  +----------------------------+   |
|                |                                                |                 |
|                v                                                v                 |
|       [Unmanaged Layer]                             [Managed Solution Layer]      |
|  (All unmanaged edits share                   (Maintains schema ownership & data) |
|   a single shared layer)                                                          |
+-----------------------------------------------------------------------------------+

Unmanaged Solutions

• Primary Purpose: Used strictly in Development environments for authoring, configuring, and organizing platform assets.
• Container Concept: An unmanaged solution does not isolate its components into an independent database partition. Instead, it serves as an organizational filter or view over the shared Active Unmanaged Customizations layer of the environment. Multiple unmanaged solutions in the same development environment share the exact same underlying assets.
• Direct Editing: Customizers can freely add, modify, or delete any component within an unmanaged solution. Any modification immediately updates the component across all other unmanaged solutions referencing that component.
• Export Flexibility: An unmanaged solution can be exported in two formats:
  1. Unmanaged ZIP package: Used for extracting source files for version control (Git) or transporting work-in-progress between sandbox development environments.
  2. Managed ZIP package: Used for packaging and deploying completed, tested assets into downstream Test, UAT, Pre-Production, and Production environments.
• Deletion Behavior: Deleting an unmanaged solution deletes only the solution container definition. All tables, columns, forms, flows, and data records created within that solution remain completely intact inside the environment's unmanaged layer.

Managed Solutions

• Primary Purpose: Used for deploying finalized solutions to non-development environments (Testing, Staging, Production) and for distributing commercial Intellectual Property (IP) by Independent Software Vendors (ISVs).
• Immutability & Lock Down: Once imported, managed components cannot be directly edited or modified within the target environment unless explicitly permitted by Managed Properties.
• Clean Uninstallation: Deleting a managed solution performs an atomic, comprehensive rollback: Dataverse uninstalls the solution container, removes all associated custom components, drops custom schema tables and columns, and permanently purges all underlying business data stored in those custom tables.
• No Direct Export: A managed solution cannot be exported from an environment where it was imported as managed. It can only be regenerated and exported from the original source development environment where it exists as an unmanaged solution.

---

2. Solution Layering Architecture & 'Top Layer Wins'

Dataverse calculates the runtime user interface, schema, and logic by evaluating a vertical stack of solution layers. When a user opens a form or executes an app, the platform computes the effective configuration by stacking layers from bottom to top.

+-----------------------------------------------------------------------------------+
|                         DATAVERSE SOLUTION LAYERING STACK                         |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | [LAYER 5: ACTIVE UNMANAGED CUSTOMIZATIONS]                                  |  |
|  | - Direct edits made in target environment (Hotfixes, personal tweaks)       |  |
|  | *** HIGHEST PRECEDENCE: WINS ALL RUNTIME CONFLICTS (Can mask updates!) ***   |  |
|  +-----------------------------------------------------------------------------+  |
|                                          ^                                        |
|                                          |                                        |
|  +-----------------------------------------------------------------------------+  |
|  | [LAYER 4: MANAGED SOLUTION PATCHES]                                         |  |
|  | - Incremental delta patches applied on top of base managed solutions        |  |
|  +-----------------------------------------------------------------------------+  |
|                                          ^                                        |
|                                          |                                        |
|  +-----------------------------------------------------------------------------+  |
|  | [LAYER 3: MANAGED SOLUTION B (e.g., Enterprise Sales Add-on v2.0)]          |  |
|  | - Installed after Solution A; overrides overlapping properties in Layer 2   |  |
|  +-----------------------------------------------------------------------------+  |
|                                          ^                                        |
|                                          |                                        |
|  +-----------------------------------------------------------------------------+  |
|  | [LAYER 2: MANAGED SOLUTION A (e.g., Core Foundation Framework v1.0)]       |  |
|  | - Base enterprise solution imported into target environment                |  |
|  +-----------------------------------------------------------------------------+  |
|                                          ^                                        |
|                                          |                                        |
|  +-----------------------------------------------------------------------------+  |
|  | [LAYER 1: SYSTEM SOLUTION (Base Dataverse Platform)]                        |  |
|  | - Out-of-the-box standard tables (Account, Contact, ActivityPointer, etc.) |  |
|  | - Default system forms, views, security roles, and platform assemblies      |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Layer Evaluation Rules

1. The System Solution (Base Layer): The lowest layer, containing all out-of-the-box system tables, standard forms, views, and core assemblies provided by Microsoft.
2. Managed Solutions Stack: Managed solutions sit above the system solution. If multiple managed solutions customize the same component, they are layered in the chronological order of installation. A managed solution imported today will layer above a managed solution imported yesterday, and its property changes will override lower managed layers.
3. Managed Solution Patches: Patches to a managed solution sit immediately above their parent managed solution layer.
4. Active (Unmanaged) Layer (Top Layer): Any unmanaged modification performed directly in the environment (e.g., an administrator editing a form directly in Production or importing an unmanaged package) sits at the absolute top of the stack.

The 'Top Layer Wins' Principle

When resolving conflicts between layers, Dataverse applies the rule: The Top Layer Wins.

• If a managed solution introduces a new field layout on a form, but an administrator previously edited that form directly in the target environment (creating an Active Unmanaged layer), the unmanaged layer sits on top and masks the managed solution changes.
• To the end user, the newly deployed managed solution updates appear to have 'failed' or 'not deployed'. In reality, the managed layer was successfully installed underneath, but the top-level unmanaged layer hides it from view.

+-----------------------------------------------------------------------------+
|                   THE UNMANAGED LAYER MASKING PHENOMENON                    |
|                                                                             |
|   [Active Unmanaged Layer]   --> Form shows: Column A, Column B             |
|             |                    (Direct edit in Prod created this layer!)  |
|             v                                                               |
|   [New Managed Solution v2]  --> Form updated: Column A, Column B, Column C |
|             |                    (Deployment succeeded, but is MASKED)      |
|             v                                                               |
|   [Old Managed Solution v1]  --> Form had: Column A                         |
|                                                                             |
|   RESULT: End users in Production only see Column A and B!                  |
|   REMEDIATION: Inspect Solution Layers -> Delete Unmanaged Customization    |
+-----------------------------------------------------------------------------+

---

3. Diagnosing and Removing Solution Layers

When troubleshooting unexpected behavior in downstream environments, functional consultants use the Solution Layers inspection interface.

Inspecting Solution Layers

1. Navigate to the Power Apps Maker portal (make.powerapps.com) in the target environment.
2. Open the relevant Solution, drill into the component (e.g., a specific Form, View, Table, or Model-Driven App), and select the ellipsis (...) context menu.
3. Select Advanced > See solution layers.
4. The interface displays the full vertical stack of layers contributing to that component, along with the Solution Name, Publisher, Version, and Date Modified for each layer.

Removing Unmanaged Layers

If an unwanted unmanaged layer is masking a production deployment:

• In the See solution layers flyout, select the top Unmanaged layer.
• Click Remove unmanaged customizations (or Delete unmanaged layer).
• Dataverse purges the unmanaged override, and the uppermost Managed Solution layer immediately becomes active and visible to all users without requiring a server reboot or redeployment.

[!IMPORTANT] Merge Behavior vs. Replacement: Not all components merge identically across layers:

• Forms & Model-Driven App Site Maps: Dataverse merges XML sub-elements (adding new tabs/sections from managed solutions alongside existing unmanaged elements).
• Views, Web Resources & Canvas Apps: The top layer completely replaces lower layers (full overwrite).
• Schema / Columns: Cumulative addition (all columns defined across all active managed and unmanaged layers exist on the table).

---

4. Managed Properties Governance

When designing managed solutions for distribution (to external clients or downstream business units), consultants can configure Managed Properties to restrict what downstream administrators can modify.

+-----------------------------------------------------------------------------+
|                        MANAGED PROPERTIES CONTROLS                          |
|                                                                             |
|   [CAN BE CUSTOMIZED]        --> Master toggle: True / False                |
|   [CAN BE DELETED]           --> Prevents downstream deletion of table/view |
|   [CAN CHANGE DISPLAY NAME]  --> Blocks renaming core business schema       |
|   [CAN ADD NEW ATTRIBUTES]   --> Blocks adding custom columns to table      |
|   [CAN CHANGE AUDITING]      --> Enforces or locks compliance audit state   |
|   [CAN CHANGE FORM PROPERTIES]--> Locks form layout and event scripts       |
+-----------------------------------------------------------------------------+

Key Managed Properties Settings

• Can be customized (IsCustomizable): The primary master switch. Setting this to False locks all properties of the component, preventing downstream administrators from altering forms, adding columns, or adjusting relationships.
• Can be deleted (IsCanBeDeleted): Prevents downstream environments from deleting the component even if they have system administrator privileges.
• Can change display name (IsRenameable): Protects corporate nomenclature by preventing downstream users from renaming standard or custom entities.
• Can add new attributes (CanCreateAttributes): Prevents downstream customizers from creating additional columns on a core enterprise table.

[!TIP] Exam ALM Rule: Always author customizations in a dedicated Development environment using Unmanaged Solutions. Never perform direct unmanaged edits in Production. Deploy to Test and Production strictly as Managed Solutions via automated pipelines to maintain a single source of truth, ensure clean rollback capabilities, and prevent unmanaged layer masking.