In a CI job, using source control as the source and including deleted items, you can run into an issue where objects from managed packages show as "deleted" in terms of custom object permissions from permission sets that have access to them. This can occur for permission sets designed to give access to managed package features or if you have a permission set with "View all data" or a system permission that gives them access to all objects in some capacity (read, write).

Ideally, we wouldn't have to include managed package object permissions into Source Control (likewise, Gearset suggests only including installed package metadata versus the details of said package).

It'd be great if Gearset would exclude the custom object permissions being deleted if it's related to an object in a managed package

OR

Add a blocker/warning about trying to remove custom object read permission on a permission set that needs access to all objects (with "View all Data")

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.

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.