In the situation where a repository is the source and an org is the target, there may be a situation where a record type doesn't exist in the repository but references in the layout permissions and custom object permissions do still exist.

Currently, the problem analyzer will catch the custom object permissions and ask you to remove the references to the record type that doesn't exist in the target.

However, it doesn't catch the layout permissions and the deployment could fail with an invalid reference.

In the absence of the record type in the repository, the "Problem Analyzer for excluding the Record Type from the Layout Permission" should trigger in the same way that the " Problem Analyzer for excluding the Record Type from the Custom Object Permission" behaves.

Sandboxes don't contain certain objects and permissions in comparison to Production and they can't be added. I find this causes issues in our CI jobs that are deploying production orgs into sandboxes unless you add a lot of customization to filters.

Since filters on a CI job don't get reflected across other CI jobs (see: https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/38727925-separate-filters-for-ci-jobs-to-reflect-filter-edi) this can be a major pain to keep them in sync and keep up to date if someone activates a features in production (ex. DevHub - which creates ScratchOrg custom object that doesn't exist in sandboxes).

Currently, we have the below noted as causing issues in Sandboxes:

Profile Permission - EditBillingInfo
Profile Permission - ManageSandboxes
Custom Object + related profile permissions - ActiveScratchOrg
Custom Object + related profile permissions - NamespaceRegistry
Custom Object + related profile permissions - ScratchOrgInfo
Custom Application - standard__LightningInstrumentation
Profile: User Permission - EditBillingInfo
Profile: User Permission - ManageSandboxes
Profile: User Permission - Packaging2PromoteVersion
Certain Report types may rely on objects that don't exist in sandboxes (LightningUsageByBrowserMetrics)

If these were caught by a problem analyzer, then our CI jobs could run with standard filters (ex. select all objects) and minimize the customization of a given filter to support several CI jobs backfilling production into different tracks/sandboxes. Right now, we have to keep a long "exclude" regex and make sure our filters are correct across many jobs.

The "repository sanitizer" performs unsolicited/silently changes which confuse users and generate issues. For instance, if you have Apex class permissions in profiles for classes which are part of a managed package and are not present in the repository, this sanitizer will modify the permissions to false which is obviously a disaster, (and the changes can happen any moment, while users are trying to deploy something completely unrelated hence the confusion).

We know the solution is to have the classes also in the repository but for managed packages that's unnecessary extra work since then we need to be updating them every time the package is upgraded.

I had a deployment fail today due to a difference between a custom metadata type's definition in the source org vs the destination. The source had two extra fields that the destination did not have. This cause the metadata record deployment to fail, because two extra values were included in the deployment which did not have corresponding fields in the destination. Because the fields were for a custom metadata package, I was unable to (easily) add the fields into the destination org.

I'd like to see a way to suppress custom metadata values. This may be solvable through the inline metadata editing feature requested on this site, though this would be annoying for large deployments.

A solution that might fit in with the philosophy of Gearset would be to add a warning to deployment that verifies if all of the values in the deployment have corresponding fields. If fields are missing in the destination, then a toggle is given that allows users to remove those field values from the deployment, without removing the entire metadata record.

Deployment of certain types of objects requires that other objects on which they are dependent be included in the deployment. If the needed objects have not been included in the selected items and they are not part of the comparison, Gearset will display the following message:

Problem: Some itmes reference componnents that were not downloaded from either the source or the target.

Solution: Removing the elements that reference missing components from the affected items will make the deployment more likely to succeed.

Below this is displayed a table with a column of checkboxes at the left and three additional columns: "Element type", "Missing component", and "Affected item".

I think two changes to this page could make it more usable:

1. In addition to advising the user on how to exclude the objects from the deployment, the UI should advise the user on what needs to be done to include them - presumably changing the parameters of the comparison so that the needed additional objects are included.




2. The table should indicate not only the name but the type of the missing object.

On the "Deployment Summary Page" it would be great to add a column to the list of metadata components added which shows for the "No Difference" items showing the source piece(s) of metadata which is causing this "No Difference" to be included.

This would dramatically help in the narrowing down of why a piece of metadata is included - especially if that piece of "No Difference" is a managed package and cannot be altered. In a large deployment, trying to identify a root cause for why a component was added is quite difficult. Simply giving a way to track back the cause will definitely help speed up the process of getting the package ready to deploy.

The problem analysis comes up with a number of Suggested Fixes which may make sense for improving Salesforce deployments, but which are unproductive when applied to git deployments.

For example, the suggestion to remove TASK.WHAT_NAME, or to omit Standard Objects, will only serve to create a git repo which is an inaccurate reflection of the source org. Each time we deploy to that git repo, we will continue to have the same changes to select or omit, since the repo is missing objects and fields from the source org.

When the deployment target is a git repo, all suggested fixes which remove fields and metadata in accordance with Salesforce best practices should be hidden/suppressed/omitted. Suggested fixes which add necessary dependencies to the deployment should still be displayed.