Dataverse Table Metadata Not Updating During Managed Solution Import

I recently encountered two unusual Dataverse solution deployment issues where table metadata changes were included in a managed solution but were not applied to the target environment during an Upgrade.

The two cases involved different table properties:

• Disabling Quick Create for the table
• Enabling auditing for several standard tables

Although the symptoms were different, the investigation indicated that both issues were related to how Dataverse processes table metadata during a managed solution import with Single step upgrade.

The first issue: Quick Create remained enabled

In the first case, the Leverage quick-create form if available setting was disabled for ones of the tables in the development environment.

The impacted table was included in the solution with table metadata, and the exported customizations.xml contained the expected value:

<IsQuickCreateEnabled>0</IsQuickCreateEnabled>

However, after importing the managed solution into the target environment using Upgrade, Quick Create remained enabled.

The setting was correctly disabled in the source environment, there was no unmanaged layer overriding the property, and the managed solution was the top solution layer.

To determine whether the table was being processed at all, a test column was added to the same table and a new version of the managed solution was imported.

The result was interesting:

• The new column was created successfully in the target environment.
• The Quick Create setting remained unchanged.
• The solution layer remained the same.

This showed that the managed solution was being imported and table components were being added, but the table-level metadata change was not being applied.

Microsoft Support investigated the behaviour and escalated it to the Product Group. Before a conclusive explanation or fix was provided, the setting was applied successfully during a later deployment, using another managed solution version.

At the time, the issue appeared to have resolved itself.

The second issue: Table auditing remained disabled

Shortly afterwards, I encountered a very similar issue with another table property.

Auditing had been enabled in the development environment for multiple standard tables.

The tables were included in the solution with table metadata. Microsoft documents that selecting Include table metadata includes properties such as auditing, duplicate detection and change tracking. Use table segmentation in solutions

After importing the managed solution into the impacted environment using Upgrade, auditing was still disabled for some of the tables.

Again, the expected metadata was present in the solution package, and there was no effective unmanaged layer that should have prevented the incoming managed property from being applied.

This time, Microsoft Support identified a possible connection with an internal optimisation referred to as SmartDiff optimization.

What is SmartDiff optimization?

According to the explanation provided by Microsoft Support, SmartDiff optimization is a back-end optimisation that evaluates changes in a solution package and attempts to process only the differences.

As part of that optimisation, some changes considered minor may not cause the complete table definition to be processed during deployment.

Smart Diff does not appear to be publicly documented in Microsoft Learn as a configurable Dataverse solution feature. Therefore, this explanation should be treated as information provided through the Microsoft Support investigation rather than as documented product behaviour.

In both cases, the managed solution package contained the correct metadata. The problem was not that the table property had been omitted from customizations.xml.

The apparent problem was that importing the solution using the standard Upgrade path did not always cause the relevant table metadata to be reapplied.

Troubleshooting attempts

Several approaches were tested during the two investigations.

Confirm that table metadata is included

When adding an existing table to a solution, selecting individual columns, forms or views does not automatically include all table properties.

Select Include table metadata when the solution needs to transport table-level settings such as:

• Auditing
• Quick Create

Microsoft documents this behaviour in Use table segmentation in solutions.

This is an important first check, but it was not the cause in these two cases. The expected metadata was already present in the exported solution.

Check the solution layers

An unmanaged active layer or a managed layer from another solution can prevent an incoming value from becoming effective.

Microsoft’s Changes aren’t effective after solution import article describes these common causes and recommends reviewing the solution layers.

In these incidents, removing the unmanaged layer did not provide a complete or repeatable resolution.

Add a dummy column

A dummy column was added to test whether changing the table would cause Dataverse to process the table metadata again.

In the Quick Create case, the new column was successfully deployed, but the Quick Create setting was still not updated.

A similar test was proposed for the auditing issue. The result demonstrated that merely adding another table component does not guarantee that all table-level metadata will be reapplied.

Modify column metadata

During the auditing investigation, Microsoft Support manually modified small values in the solution’s customizations.xml, such as a column length or weight, before repackaging and importing the solution.

That import caused auditing to become enabled in the support environment.

Changing the relevant column metadata resulted in a more significant difference being detected, which appeared to force Dataverse to process the table definition again.

Directly editing customizations.xml was useful as a diagnostic test, but it was not an appropriate long-term deployment approach.

Import using Update

Microsoft Support also found that importing the managed solution using Update could apply the metadata change when Upgrade did not.

However, Update and Upgrade have different ALM behaviours.

With Update, components that have been removed from the newer solution are not deleted from the target environment. This can cause the source and target environments to diverge.

With Upgrade, components that were part of the previous managed solution but are no longer included in the new version are removed.

Microsoft documents these differences in Update a solution.

Using Update was therefore not suitable as the standard deployment approach for this project.

The solution: Stage for Upgrade and Apply Upgrade

After further investigation with the Microsoft Product Team and Technical Advisor, Microsoft Support recommended testing the two-step upgrade process:

1. Import the managed solution using Stage for Upgrade.
2. After staging completes successfully, select Apply Upgrade.

The process was first tested in the support environment and appeared to process the table metadata correctly. It was then verified during an actual environment which was impacted.

The managed solution was imported using Stage for Upgrade, followed by Apply Upgrade. The Audit property on the impacted tables was updated successfully without adding a dummy column or manually modifying customizations.xml.

Microsoft describes Stage for Upgrade as installing the higher solution version while deferring removal of the previous version and related patches until Apply Upgrade is performed.

The final result is still an upgraded managed solution, including removal of components that are no longer present in the new version.

Why the two-step process worked

The support investigation indicated that Smart Diff is skipped in certain import scenarios, including a staged upgrade.

Based on the observed results, using Stage for Upgrade followed by Apply Upgrade caused Dataverse to process the table metadata that the standard single-step Upgrade had previously skipped.

This provides a plausible explanation for both incidents:

• The solution package contained the correct table metadata.
• Individual table components could still be deployed.
• The table-level property did not change during a standard Upgrade.
• The property was applied when a different import path caused the table definition to be processed again.

This is based on Microsoft Support’s investigation and the results observed in the support and impacted environments. It is not currently documented as a general Smart Diff guarantee in Microsoft Learn.

Recommended troubleshooting process

If a Dataverse table property is present in a managed solution but is not updated in the target environment, I would check the following:

1. Confirm that Include table metadata was selected for the table.
2. Extract the managed solution and verify that the expected property exists in customizations.xml.
3. Review the solution layers for unmanaged customisations or another managed solution above the expected layer.
4. Confirm that the correct managed solution version was imported.
5. Test the solution in a non-production environment using Stage for Upgrade followed by Apply Upgrade.
6. Verify the affected table property after Apply Upgrade completes.

Final thoughts

These incidents were not specific to auditing or Quick Create. They affected different table properties but followed the same pattern: the table metadata was present in the managed solution package, yet it was not applied during a standard managed solution Upgrade.

If a table property is not updating, first rule out the usual causes such as missing table metadata and solution layering. If those checks are clean, the behaviour may be related to how Dataverse determines which metadata differences need to be processed during the import.

In this case, importing with Stage for Upgrade and then running Apply Upgrade successfully applied the table metadata while preserving the required Upgrade behaviour.