In an org to org comparison, if you are trying to compare managed package subcomponents (such as a managed custom field on a non-managed custom object) you may find it confusing that they don’t always show up in your comparison results. This article explains why this is happening.
In the section Prerequisites for managed package metadata to appear in your comparison results in this article, we note that there are two ways to view managed package metadata components.
These depend on whether you have the Installed package metadata type included in your metadata filter or not.
As a result, if your source and target have differing versions of a managed package (or the managed package does not exist in one of your orgs), you will see the following behavior:
If the
Installed packagemetadata type is not included in your metadata filter, the managed package subcomponents will appear in your comparison results.If the
Installed packagemetadata type is included in your metadata filter (e.g. you use theDefault comparisonfilter), some of the managed package subcomponents may not appear in your comparison results.However, you will generally see "New", "Different" or "Deleted" managed package items for the
Installed packagein your comparison results. But they will not be identified as sub-components of a managed package they belong to.
Let's take a look at some comparison results examples in our 'Compare now' interface:
Example for point 1:
On below screenshot we have comparison results where trailheadapp is installed in both the source and target orgs.
But because Installed package metadata is included in the metadata filter (of this comparison), we don't see any dependencies of the trailheadapp directly under its managed package namespace ("trainheadapp") as highlighted in red.
Expected behavior
Instead, the expected behaviour is that the sub-components of the trailheadapp managed package can be found within the comparison results as independent components (as highlighted in blue).
You can use the filter in the top right to try to locate these sub-components if you know the name of a sub-component you're looking for.
Note: This behaviour is expected to be seen regardless of whether Include managed packages is set to "None" or "All", or if you decide to select "Choose" and include only specific managed package(s) in your comparison results.
Example for point 2:
On below screenshot we have compared the same source and target orgs where the trailheadapp is installed in both orgs.
Our metadata filter configuration is set to:
- Installed package metadata unselected (excluded from the comparison)
- Include managed packages option set to All (to retrieve all managed packages from source and target)
Expected behavior
All the sub-components of the trailheadapp are showing up in the comparison results when Include managed packages option is set to All.
And as long as Installed package metadata type remains unselected in the filter.
What other aspects should I consider?
It's important to note that Gearset can only detect different versions of managed packages if Installed package is included in your metadata filter.
If the managed package versions are different, those detected metadata differences could well be a result of version difference (new components etc) and not user customization. Accordingly, Gearset prevents those subcomponents from appearing in your comparison results.
Understanding this, you will need to decide if you want Gearset to know that the managed packages versions are different or not, and adjust your metadata filter accordingly.
Are you looking for more advanced filtering options?
For more advanced filtering options that allow you to include and exclude specific items in your metadata filter, you may want to take a look at the Regex feature: Using regex in custom metadata filters.