Power Apps Ribbon Customization: Effectively Remove Unmanaged Layers for Optimal Control

Table of Contents

Customizing the command bar (formerly known as the ribbon) in Power Apps model-driven apps is a common requirement for tailoring the user interface to specific business processes. While Power Apps provides powerful tools for this customization, managing these changes effectively across different environments can become challenging. A significant hurdle arises from the creation and persistence of unmanaged layers, particularly in environments where changes are made directly outside of a managed solution deployment process. Understanding how to identify, analyze, and effectively remove active unmanaged layers is crucial for maintaining control, ensuring predictable behavior, and facilitating seamless application lifecycle management (ALM). This article delves into the complexities of solution layers in Power Apps, focuses on the issues caused by unmanaged layers in the context of ribbon customization, and provides strategies and steps for their removal, ultimately leading to more robust and maintainable applications.

Understanding Solution Layers in Power Apps¶

Power Apps utilizes a layering concept to manage customizations applied to components like tables, forms, views, and commands. This system ensures that multiple customization efforts, potentially originating from different sources (publishers, solutions, direct environment changes), can coexist and be applied in a predictable order. When a component is displayed or used, the platform evaluates all applicable customization layers to determine the final effective definition of that component.

At a high level, these layers include the base layer (representing the default configuration), followed by various solution layers, and finally, the active layer, which represents the combined result of all underlying layers, potentially including unmanaged customizations made directly in the target environment.

Managed vs. Unmanaged Solutions¶

The layering model heavily relies on the distinction between managed and unmanaged solutions.

• Unmanaged Solutions: These are used for development and testing within a specific environment. Components within an unmanaged solution can be directly modified in that environment. When an unmanaged solution is exported, it carries the component definitions, but it does not enforce layer management upon import into another environment. Importing an unmanaged solution into an environment essentially merges the customizations with the existing active layer. Changes made directly in an environment’s customization interface (outside the context of importing a managed solution) also contribute to the active unmanaged layer. This is often the source of problems.
• Managed Solutions: These are intended for deployment to testing, staging, or production environments. When a managed solution is imported, it creates a managed layer above any existing unmanaged layers but below the active unmanaged layer (if one exists). Managed layers protect the customizations within them; these customizations cannot be modified directly in the target environment. Uninstalling a managed solution removes its specific layer, rolling back the environment to the state defined by the layers below it.

The Hierarchy of Solution Layers¶

The order in which layers are applied determines the final state of a component. The hierarchy, from lowest to highest precedence (meaning higher layers override lower ones), is generally:

1. System Layer (Base definition)
2. Managed Solution Layers (applied in installation order - oldest first, latest last)
3. Unmanaged Customizations (The active unmanaged layer)

This hierarchy means that any direct change made in an environment creates an unmanaged layer that sits at the very top, overriding all managed solution layers beneath it. This is where the challenge with unmanaged layers impacting ribbon customization often arises. If you deploy a managed solution that customizes a ribbon, but later someone makes a direct change to that same ribbon in the target environment, that direct change creates an unmanaged layer that takes precedence, potentially blocking or altering the intended behavior from the managed solution.

The Challenge of Unmanaged Layers in Ribbon Customization¶

Ribbon customization, particularly for model-driven apps, involves defining buttons, tabs, groups, and their behavior. These customizations are stored as metadata within the environment. When you modify a ribbon element directly in an environment (e.g., using the classic editor or modern command bar editor outside the context of a specific solution you are developing in), these changes are saved into the active unmanaged layer for that component.

The presence of unmanaged layers on command bar components can lead to several issues:

• Blocking Managed Updates: If you deploy a new version of your managed solution containing updated ribbon customizations, the existing unmanaged layer in the target environment will override the incoming managed layer. Your new customizations won’t appear or behave as expected because the unmanaged layer takes precedence.
• Inconsistency Across Environments: Unmanaged changes are specific to the environment where they were made. Deploying the same managed solution to multiple environments will result in different ribbon behaviors if each environment has unique unmanaged layers on the command components.
• Difficulty in Troubleshooting: When unexpected ribbon behavior occurs, the presence of unmanaged layers makes it harder to diagnose the root cause. You have to investigate multiple layers to understand which rule or definition is currently being applied.
• ALM Complexity: Managing deployments and updates becomes significantly more complex when dealing with environments littered with unmanaged customizations. It breaks the principle of deploying consistent, tested packages.
• Lack of Version Control: Unmanaged changes are not inherently tied to a solution version in the same way managed layer changes are. This makes tracking and reverting specific unmanaged changes difficult.

Consider a scenario: You have a managed solution that hides a button on a form’s command bar. You deploy it to production, and the button is hidden. Later, an administrator in production, without realizing the impact, manually shows the button again using the command bar editor. This action creates an unmanaged layer that overrides the managed layer from your solution. Now, the button is visible. When you deploy an update to your managed solution, the unmanaged layer persists and continues to show the button, making it seem like your update failed.

Identifying and Analyzing Unmanaged Layers¶

Before attempting to remove unmanaged layers, you must first identify which components are affected and analyze the nature of the unmanaged customizations. Power Apps provides tools to inspect the solution layers for any component.

The primary tool for this is the Solution Layer Checker. You can access this tool through the modern solution explorer or the classic experience.

Steps to check solution layers:

1. Navigate to make.powerapps.com.
2. Select the environment you want to inspect.
3. Go to Solutions.
4. Open the solution that contains the component you are interested in (or simply navigate to the component directly under Objects like Tables, Apps, etc., although using solutions is recommended).
5. Find the component you want to examine (e.g., a specific table, and then navigate to its forms or command bars, or directly navigate to a model-driven app). For command bar customizations, you’ll typically look at the component (like a Table or App) where the ribbon is located and then potentially drill down or use the layer checker on the component itself.
6. Select the component. In the ribbon or context menu, look for the “See solution layers” or a similar option. This opens a dialog or side pane showing all layers applied to that specific component.

Analyzing the Layers:

The solution layers view displays a list of layers applied to the component, ordered from lowest (System) to highest (Active/Unmanaged).

• Look for layers with the type “Unmanaged”. If an “Unmanaged” layer exists and is the topmost layer, it means direct changes have been made in this environment, overriding any managed solution layers below it.
• Examine the details of the unmanaged layer if possible. The tool might show the properties that have been modified directly, although for complex command bar XML this can be difficult to interpret fully within the UI.
• Pay close attention to the date and time the unmanaged layer was created, as this can help identify when the direct modification occurred.

For ribbon customizations specifically, the layer checker will show layers on the component the ribbon belongs to (like the Account table, or a specific model-driven app). You might need to analyze the command definitions themselves to understand the specific unmanaged change affecting the ribbon. This might involve exporting customizations XML or using specialized tools like the Ribbon Workbench, although the Ribbon Workbench often works within a solution context, the result of direct manual changes is what creates the unmanaged layer shown by the layer checker.

Strategies for Removing Unmanaged Layers¶

Removing unmanaged layers, especially those affecting critical components like ribbons, requires careful consideration. Simply deleting customizations can lead to unexpected data loss or broken functionality. The goal is typically to remove the unmanaged layer so that the underlying managed layer (representing your intended configuration deployed via a managed solution) becomes effective again.

There are a few primary strategies for tackling unmanaged layers:

1. Export and Re-import the Component (or Solution) as Managed: If the unmanaged layer is on a component that is part of a solution you manage, you can export the current state of that component from the environment where the unmanaged change was made (exporting the unmanaged solution), then import that component back into a development environment where you have the unmanaged version of your solution. This captures the unmanaged change into your development solution. Then, you can export your solution as managed and import it into the target environment. The managed import replaces the component definition, effectively removing the old unmanaged layer. Caveat: This method replaces the entire component definition and might inadvertently remove other legitimate managed customizations from different solutions layered beneath yours if not handled carefully. It’s often better suited for bringing unmanaged changes into your dev environment for proper management.
2. Remove Active Customizations using the Solution Layer Checker: This is often the most targeted approach for removing only the top-most unmanaged layer on a specific component. The Solution Layer Checker UI provides an option to “Remove Active Customizations” or a similar phrase. This action specifically targets and deletes the highest unmanaged layer for that single component, allowing the next layer down (ideally, your managed solution layer) to take precedence.
3. Leverage the Power Platform CLI (PAC CLI): For more advanced scenarios or automation, the PAC CLI provides commands (pac solution clone, pac solution pack, pac solution unpack, pac solution delete-layer) that offer granular control over solution layers and can be scripted. This allows for powerful ALM scenarios but requires command-line familiarity.

For the specific case of removing unmanaged layers affecting ribbon customization, the most common and safest method is often using the Solution Layer Checker UI (#2), as it allows you to target the removal precisely to the single component with the offending unmanaged layer.

Step-by-Step Guide: Removing Unmanaged Ribbon Customization Layers via UI¶

Let’s focus on the UI-based removal using the Solution Layer Checker, as it’s the most accessible method for administrators and developers.

Scenario: You have deployed a managed solution that customizes the command bar on the ‘Account’ table form. Later, someone made a direct change to this command bar in the production environment, creating an unmanaged layer that is causing unexpected behavior. You want to remove this unmanaged layer so your managed solution’s customization takes effect again.

Steps:

1. Navigate to the Environment: Log in to make.powerapps.com and ensure you have selected the correct environment where the unmanaged layer exists.
2. Locate the Affected Component:
   • Go to Solutions and open the managed solution that should be controlling this ribbon customization.
   • Find the component related to the ribbon. For command bars on standard tables/forms, this is typically the Table component itself (e.g., ‘Account’). For app-level command bars, it might be the Model-driven App component.
3. Access Solution Layers:
   • Select the relevant component (e.g., the ‘Account’ table).
   • In the command bar or context menu, click ”…” or “More commands” and look for the “See solution layers” option. Click it.

4. Identify the Unmanaged Layer:

   • The Solution Layers dialog will open, showing all layers applied to the component, ordered from bottom to top.
   • Scroll to the top of the list. Look for a layer listed as Type: Unmanaged. This is the active unmanaged layer you need to remove. Verify that it is indeed the topmost layer.

   mermaid graph TD A[System Layer] --> B{Managed Solution 1 Layer} B --> C{Managed Solution 2 Layer} C --> D[Unmanaged Layer - Direct Change] D --> E(Active Layer - Final State)
   * In this diagram, the Unmanaged Layer D overrides C and B. Removing D makes C the effective top layer before the final Active Layer E is computed.

5. Remove Active Customizations:

   • While viewing the Solution Layers, look for a button or link, typically at the top or bottom of the layer list, labeled “Remove Active Customizations”.
   • Important: Clicking this button will delete the entire top-most unmanaged layer for this specific component only. It will remove all direct customizations made to this component in this environment. Make sure you understand the implications before proceeding.
6. Confirm the Action:
   • A confirmation dialog will appear, explaining that the unmanaged customizations will be removed and the underlying managed solution layers will become effective again.
   • Review the message carefully and, if you are certain, click “Remove” or “Yes” to proceed.
7. Verify the Removal:
   • The Solution Layers dialog should refresh or close. You can reopen it to confirm that the “Unmanaged” layer is no longer present at the top.
   • Navigate to the model-driven app and form where the command bar is located and verify that the customization from your managed solution is now correctly applied and the unwanted unmanaged change is gone. You might need to clear your browser cache or perform a hard refresh to see the changes immediately.

This process effectively “resets” the component’s definition in that environment back to the state defined by the highest managed layer, eliminating the direct, unmanaged override.

Best Practices for Managing Customizations¶

Preventing the creation of problematic unmanaged layers is far better than having to remove them later. Adopting robust ALM practices is key.

• Work within Solutions: Always make customizations within the context of an unmanaged solution in a dedicated development environment.
• Use Dedicated Environments: Have separate environments for development, testing, and production. Avoid making any customizations directly in testing or production environments.
• Deploy Managed Solutions: Always export and import solutions as managed when moving to testing, staging, or production environments. Managed solutions provide layer protection and easier uninstall/rollback capabilities.
• Maintain Source Control: Integrate your development environment with a source control system (like Azure DevOps or GitHub) to track changes to your unmanaged solutions.
• Document Changes: Keep clear records of customizations and their purpose.
• Regularly Review Solution Layers: Periodically check critical components in your environments for the presence of unexpected unmanaged layers.
• Train Users/Admins: Educate administrators and power users on the importance of not making direct changes in production environments and the correct process for requesting customizations.

By adhering to these practices, you minimize the chances of encountering unmanaged layer issues and ensure a smoother, more predictable application lifecycle for your Power Apps solutions, including intricate customizations like command bars.

Preventing Future Unmanaged Layers¶

Eliminating unmanaged layers is not just about cleanup; it’s also about establishing processes to prevent their recurrence.

• Strict Governance Policies: Implement organizational policies that prohibit direct customizations in non-development environments.
• Environment Security Roles: Configure security roles in testing and production environments to restrict permissions for making customizations directly. Limit who can modify solution components.
• Training and Awareness: Provide training to all personnel working with Power Platform environments on the ALM process, the difference between managed and unmanaged solutions, and the impact of direct customizations.
• Automated Deployment Pipelines: Utilize tools like Azure DevOps or GitHub Actions with the Power Platform Build Tools to automate solution deployments. Automated pipelines enforce the use of managed solutions and reduce manual steps where errors or direct changes can occur.
• Customization Requests Process: Establish a formal process for requesting and implementing customizations. All changes should go through the development, testing, and managed deployment cycle.

Implementing these preventative measures establishes a foundation for a healthy Power Platform environment where customizations, including those affecting the command bar, are managed effectively through controlled processes and managed solutions. This results in more stable applications, easier updates, and simplified troubleshooting.

Conclusion¶

Effective management of solution layers is fundamental to successful Application Lifecycle Management in Power Apps. Unmanaged layers, while sometimes created unintentionally through direct environment modifications, can pose significant challenges, particularly when they interfere with intended customizations like those on command bars. By understanding the layer hierarchy, identifying unmanaged layers using tools like the Solution Layer Checker, and employing targeted removal strategies, administrators and developers can regain control over their application’s behavior. Coupled with best practices focused on working within solutions, using managed deployments, and preventing direct changes in production, teams can significantly reduce the occurrence of unmanaged layer conflicts and ensure that their ribbon customizations, and all other component configurations, behave predictably and consistently across environments.

Share Your Experience¶

Have you encountered challenges with unmanaged layers affecting your Power Apps ribbon customizations? What strategies have you found most effective for managing and removing them? Share your experiences and tips in the comments below!