Similar to being able to disable validation before performing a data deployment it would be very useful if there was an option to automatically uncheck the "Restrict picklist to the values defined in the value set" option for some or all of the picklist fields in a deployment.

We have data that includes picklist values that are no longer active this causes errors on individual records as part of the load. Currently I have to pick through all the errors manually then uncheck the option for the corresponding picklists fields on the target org. Then after performing the deployment I have to go back and restrict the values again - this takes a lot of time!

The ObjectTerritory2Association object does not get populated in the target org for accounts that are manually assigned to territories. This object is used by Territory Management 2.0 and holds the association between accounts and territories. After the deployment, I can see that this bridge object did get populated with the territory linkage for accounts that are automatically assigned to territories. This is expected because an insert of a new account with proper firmographic information will result in the account getting tagged to the correct territory (i.e. if the Account’s “Exclude From Territory” flag is not set to True).
However, there is no option that I can see to include this object in the list of objects to deploy. We need this to carry over the manual territory assignment information to the target org.
A common use case is to populate a sandbox with current territory information so that users can do "what if" territory realignment scenarios using current data without impacting production.

User email are masked in Sandboxes and we can mask Contact emails as part of the data deployment. This still leaves the Org Wide addresses as valid emails. If there is automation that is generating emails related to the data that is loaded, they will be delivered to the Org Wide Addresses.

It would be useful if the same script that is deactivating validation rules could set email deliverability to systems emails at the same time.

In the even that email deliverability was set to all emails in the Sandbox and not adjusted before the data deployment we would have an extra safety net to prevent emails from going out.

When attempting to validate a deployment, and the validation fails, Gearset retains the deployment's friendly name and notes fields from the validation. The user can make any necessary changes to the deployment, and won't have to re-type this information when attempting it a second or third time.

I'd like to see this same functionality when dealing with a failed deployment that doesn't use validation. Validating a package takes two steps (long steps), and typically I only want to use this option when delaying a deployment. However I often use it anyway just so I can retain my data in these two fields. It would save time to have the system remember the information for you.

Gearset allows the selection of multiple External ID's in an Upsert operation as part of a Data Deployment.

However, the system implements an 'AND' combination across all the external ID's specified on the object.
Effectively, ALL external ID's need to be present on the target side for the match to be identified and record upserted. If all external ID's are not present, the system performs an Insert on the target org.

Please allow an 'OR' combination across multiple External ID's. Arguably, this should be the default option, but at the very least, a user needs the ability to decide how they want multiple external ID's to be interpreted.

We have a large org and need to select many filters. A comparison take ages. Source of our deployments is mostly Git, which is very fast in retrieving metadata. I would like to have an option, to assume that nothing has changed in target and skip loading metadata of that org and use the metadata of an earlier comparison.
If we have a small bug in our Git (e.g, test class not correct), we get an error while deployment. That's okay. We fix it in about 1min and want to deploy again. Loading metadata from Git is instant finished loading the metadata from the org need about 20-30 minutes. And we can guarantee, that nothing has change in the target. It is very annoying to wait so long, for just a little thing.