When the Power Apps Grid Control Won't Stick: Digging Past the Layers

Chris Groh
3 days ago
3 min read

The Power Apps grid control (formerly known as the editable grid) is a welcome upgrade for model-driven apps — it offers inline editing, sorting, filtering, and a generally more modern experience. Microsoft's documentation for enabling it is straightforward, and in most environments, the switch goes smoothly. But what happens when you follow every step correctly, deploy to QA, and the change simply doesn't take hold? No error, no warning — the old grid just keeps showing up.

We ran into exactly this situation on a system we'd recently inherited. This post walks through how we diagnosed the root cause and resolved it, in case your team hits the same wall.

Background

After taking over maintenance for an existing Dynamics 365 implementation, we set out to enable the Power Apps grid control on the Opportunity table. The process is well-documented by Microsoft:

Power Apps grid control in Power Apps – Microsoft Learn

We made the configuration change, packaged it into a solution, and deployed to QA. The grid looked exactly the same as before.

Troubleshooting

Step 1: Check for an Unmanaged Layer

The first instinct when a customization isn't applying is to check for a conflicting unmanaged layer. In the model-driven app, we navigated to the Opportunity table, selected Show Layers, and looked for any unmanaged entry that might be overriding our solution component.

There was nothing there.

Step 2: Verify the Configuration is in the Solution

To confirm our change had actually made it into the solution package, we exported and unzipped the solution file and searched the XML. The configuration was there — the solution contained the correct control definition for the Opportunity entity.

So the change was packaged correctly, it just wasn't winning at runtime. That pointed to a layering conflict elsewhere — one that wasn't surfacing through the standard UI and wasn't showing in the "Solution Layers Explorer" Xrm Toolbox Tool.

Step 3: Find the Correct Component ID

The standard Show Layers UI surfaces layers for most component types, but we were unable to locate layering for CustomControlDefaultConfig. We did spot that there was a table with that name though. So we queried it.

https://<orgname>.crm.dynamics.com/api/data/v9.1/customcontroldefaultconfigs?$filter=primaryentitytypecode eq 'opportunity'

In the returned JSON, locate the customcontroldefaultconfigid value. In our case it was:

"customcontroldefaultconfigid": "4fb77cfa-4f87-48f7-be50-96e863e1f58f"

Step 4: Query the Solution Layers for That Component

With the component id in hand, we queried the msdyn_componentlayers table directly to see every solution layer for this component:

https://<orgname>.crm.dynamics.com/api/data/v9.1/msdyn_componentlayers?$filter=msdyn_componentid eq '4fb77cfa-4f87-48f7-be50-96e863e1f58f' and msdyn_solutioncomponentname eq 'CustomControlDefaultConfig'

If the results have an entry for "msdyn_solutionname":"Active", that indicates you have an unmanaged layer. We had one so now it was just a matter of removing it.

Step 5: Remove the Unmanaged Layer

To remove the active/unmanaged layer, we used the RemoveActiveCustomization action.

We used the script below. It can be run in the browser console on any standard model driven app page. If running for yourself, replace the Id with the component id for your table in your system.

(async function removeUnmanagedLayer() {
  try {
    const request = {
      LogicalName: "customcontroldefaultconfig",
      Id: { guid: "4fb77cfa-4f87-48f7-be50-96e863e1f58f" },
      getMetadata: function () {
        return {
          boundParameter: null,
          operationName: "RemoveActiveCustomization",
          operationType: 0,
          parameterTypes: {
            LogicalName: {
              typeName: "Edm.String",
              structuralProperty: 1
            },
            Id: {
              typeName: "Edm.Guid",
              structuralProperty: 1
            }
          }
        };
      }
    };

    const response = await Xrm.WebApi.online.execute(request);

    if (!response.ok) {
      let message = "RemoveActiveCustomization failed.";
      try {
        const body = await response.json();
        message = body?.error?.message || message;
      } catch {}
      throw new Error(message);
    }

    console.log("[SUCCESS] Unmanaged layer removed.");
  } catch (error) {
    console.error("[ERROR] RemoveActiveCustomization failed:", error?.message || error);
  }
})();

After running this, the unmanaged layer was gone. Our deployed solution now had the highest-priority definition for that component, and the Power Apps grid control started rendering correctly in QA.

Insights