In a recent release, we introduced more granularity to Gearset’s metadata filter - as eagle-eyed users might have noticed in our change log. Many of the improvements we make to Gearset start out as user requests on our feedback forum, and several users had asked us for the ability to select subcomponents in the metadata filter. In this post I’ll explain the use case for filtering out subcomponents from a comparison, so you can get the most out of Gearset’s metadata filter.
Why does more granular filtering help?
When you run a comparison in Gearset, the metadata filter determines which metadata types Gearset fetches from Salesforce, and you can then select the items you want to deploy. But now the metadata filter can also be used to exclude Custom Object subcomponents from the comparison after Gearset has fetched metadata from the API.
There has always been granular control over the items you deploy with Gearset. Before this latest improvement, while you couldn’t filter subcomponents out of the comparison altogether, you could select which subcomponents to deploy from the comparison results. This worked fine in the majority of cases. But sometimes it’s useful to filter certain subcomponents out of the comparison altogether.
The ListView subcomponent of Custom Objects is a good example. ListViews are created by users in the production org, and so tend to change frequently. As a result, comparisons in Gearset show all of the new or changed ListViews in production. In a manual deployment, ListViews are unnecessary noise in the comparison results - but they can just be ignored. It’s trickier with CI jobs. If you want to include Custom Objects in a CI job, those ListViews in production will be overwritten. This is why it’s so useful to be able to filter out the ListViews subcomponent: the CI job can deploy other Custom Object subcomponents, without touching ListViews.
Filtering out subcomponents from change monitoring jobs also removes unnecessary noise.
How to filter for subcomponents
In the new and improved metadata filter, you can now select or deselect individual Custom Object subcomponents. This means you can remove subcomponents, such as ListViews, from the comparison.
In the example shown above, Gearset will still retrieve the whole Custom Object from Salesforce, but remove all ListView components before rendering the comparison results. You can filter for subcomponents in deployments between any type of Salesforce org or Git repo. You can also adjust the metadata filter for any automation job, such as your continuous integration jobs.
You don’t need to do anything if you want Gearset to compare all subcomponents as before. When you select Custom Objects in the metadata filter, all subcomponents are included by default, so the number of metadata components in your existing jobs or comparisons won’t be affected.
What next?
So far, we’ve only made this change for Custom Objects. If there are any other metadata types for which you’d like to filter down to the subcomponent level, let us know. You can vote for other user requests on our feedback forum - or leave your own!
New to Gearset? Check out our videos to help you get started, or ask us anything via the live chat!