In some cases, items in the comparison results show up as Different, but when you look at the XML, the difference is purely in the order of the XML elements.

In the screenshot below, the source and target XML have the same meaning, but lines 10 and 14 are returned in a different order. As a result, this shows up as a difference to Gearset. In some ways, this is a false positive, as the overall meaning of the item is the same in both environments. 

One of the most common examples of this is the Layout metadata type as shown in the screenshot below.

Why does this happen?

This happens because the Salesforce metadata API is not always consistent in the XML order when returning XML elements. 

Without changing the meaning of the org's metadata, the ordering of the XML elements of the same org can also be different between two consecutive retrievals.

Gearset’s comparison engine then sees this as a difference in the file, as the XML has been changed.

Why doesn’t Gearset ignore XML reordering? 

We sometimes get asked if we can re-order the XML elements to remove these false positive “changes” from the comparison results. There are two reasons the app doesn’t do this:

  1. The XML order is important for some elements - e.g. picklists. If we were to re-order the XML, the order of the picklist values would be altered, which introduces unwanted changes in the deployment.
  2. Which metadata types are affected, and the nature of the reordering, is inconsistent in the metadata API. This makes it hard to reliably predict which components are are expected to have false positives, and which are genuine ordering differences.

As frustrating as ordering-only differences can be, they're a difficult one to fix due to the inconsistencies of the Salesforce metadata API. If you think we're missing something or think we should hide them even when the ordering is significant then get in touch!

Did this answer your question?