Valerio recommended that I post this suggestion following a discussion on 29 August 2019.

Issue reference:
https://docs.gearset.com/en/articles/3226459-a-note-on-deploying-custom-object-permissions-on-new-profiles

Issue:
1. Remove all object-level access for "Lead" from a custom profile in a source org
2. Deploy this profile to a target org
3. The profile in the target org will have access to the "Lead" object ENABLED, because this access is included in the Standard User profile (see document link above)

The workaround (deploying and then deploying again) is cumbersome and not always practical, e.g. if making automated, one-step deployments outside of Gearset. Failing to make a second deployment means that users with the profile will have access to objects that they should not, which is a major security risk.

I suggest that you add the option to explicitly add permissions to the XML, even where these are not provided by the Salesforce metadata API. So in this example, if the Lead object's permissions are omitted from the profile, generate the explicit XML definition for that and let me commit that definition to the target repository.

Copado offers this option, albeit for all permissions within the profile:
https://docs.copa.do/article/ob0eyv4wk6-commit-full-profiles-and-permission-sets

Relevant part from link above: "The Full Profiles & Permission Sets feature does not follow the standard behavior of the metadata API during the retrieve of system permissions. Unlike the regular profile or permission set commits, the turned off system permissions will be committed in the XML with the tag enabled as false."

Salesforce has begun adding User metadata to fields. One good example right now is the "Data Owner" field that appears on all custom fields now (in XML this field is labelled as "BusinessOwnerUser"). The field does not link via a Salesforce ID; it instead displays the Salesforce Username of the user.

Naturally, this field in 99.9% of Salesforce environment comparisons is going to be different. "user@domain.com.sandbox" won't ever match to "user@domain.com" in production-- and it definitely won't ever match to any other Sandbox, either.

This leads to a nightmare scenario where if this field has been populated on any field, that field will always (ALWAYS) show up under "Differences" in any environment comparison. Moreover, if it's included in a deployment by accident, that deployment will fail since the assigned user won't exist on the target environment.

This means that organizations who use fields like this are blocked from executing comparisons based on Custom Fields-- which is a core benefit of Gearset. Yes-- it's technically possible to laboriously review each and every custom field in the differences comparison every time, assessing if there's an 'actual' change or not-- but this is not realistic.

To resolve this, I recommend one or more solutions:

1. Exclude "User" metadata like this --always-- from all comparisons (or make this an option we can opt in/out of)




2. Compare the "User" metadata between source & target, and if the prefix to the final suffix is identical, ignore differences. This ensures that as long as you don't edit the User data outside of production environments, you can at the very least keep your User metadata preserved throughout the stack.

Until this is resolved, the only workaround is to 100% ignore using fields such as "Data Owner", because Gearset cannot currently support the type of comparisons with this field effectively. This may not be the best course of action for many businesses (ours included).

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.

Our organization has now done over 13,000 deployments (yay!), but that means when I have to search for past deployments, any searching beyond 10 days as the filter becomes an impossible task because of the sheer volume that has to be searched (boo).

When trying to combine successfully deployed packages into a new package, if I have to change the date range to find a deployment done several months ago, I lose the selected deployments from a more recent timeframe and can't select them all to combine neatly.

If we could see successful deployments by viewing the authorized Org in the system, like a Related List, for successful deployments that I could then combine to another related instance deployement, that woudl be amazing. Would also be great for seeing related Validated Packages, and Monitoring jobs, it would make our lives so much easier.