Hello,
I want suggest an option to avoid run unit tests when no have apex class in the package.
And run all tests when have any apex class in the package.

https://developer.salesforce.com/docs/atlas.en-us.apimeta.meta/apimeta/meta_livechatbutton.htm

LiveChatButton metadata that is routed using OmniChannel is not supported with the Metadata API and the deployment will fail.

It would be great if Gearset had an analyzer to remove this for end-users to prevent the error.

The following property is null for LiveChatButtons routed through Omni-Channel

<routingType xsi:nil="true" />

Need to have JIRA integration with Data Deployments which will improve the process and allign it with meta data deployments

Can you add the Salesforce ID to the Export History button for reconciliation purpose.
We currently have to manually match the Salesforce ID in Gearset with the Salesforce ID on the Salesforce Deployment Status page to get the reference between the source ticket in Jira and the deployed change for compliance purpose which is a time consuming process.

When comparing XML for RecordType permissions in Profiles, some Sandboxes return:
<personAccountDefault>true</personAccountDefault>

As part of the XML, even though person accounts are not enabled, this makes comparing annoying.

It would be nice to have an option to ignore this.

It would be great to be able to export the list of unit tests and their respective code coverage in a csv file for further internal processing.

After selecting the source org and viewing the metadata comparison filters, there should be an option to only show those types that contain data (the ones that have a number in parentheses). Or in other words... the ability to hide anything that isn't being used.

This would make it much faster to create new comparisons (or troubleshoot existing ones).

When we check Validate pull requests targeting the source branch for the Pull request , it runs all the test class irrespective of the package content that being pushed.
It should not run any test class if pushed metadata is only configuration.
It should run only test class if pushed metadata ha class.

When choosing a template in a Data deployment, an option to search all templates is needed. We will be updating/modifying/saving new templates often and a manual scroll will become inconvenient. Control F works to find a template, but a dedicated search option would be preferable

Having the option to move up only selected fields in a Data deployment is needed. If we are required to move up all fields in each deployment, there are scenarios where our work will get bottlenecked in a sandbox on the way to production and at that point all the deployments will be identical.

It would be very useful to be able to see the details behind data deployment templates and manage / rename them

When deploying, we have standard options for running tests. It would be great, if we have an option for "auto-specified tests" where Gearset would automatically find test classes for classed being deployed.
It can be done that in Setup, the team will define what type of extension the test classes has and then Gearset would use that key to find matching test classes.
E.g. we have the class "AccountServices" and we have developed a standard set that the test class has extension "Test", so "AccountServicesTest". In the Gearset setup we would set the variable for tests to "Test".

E.g when you want to move data from PROD to DEV there are some fields (e.g. Contract Status) that you want to move from Active to Draft. This should be a generic function also to be applied to other fields / objects.

It should be possible to have gearset to deactivate flows and/or processes based on a selection. And to roll-back afterwards. Similar to what has been created here: https://sfswitch.herokuapp.com/

When you are in the data deployment setup you need to click each and every object. it's better to add a check box to include everything automatically based on a filter

Before you deploy but after you start the process it should be possible to refresh / empty cache to make sure that any updates to the meta data in either source or target are updated.

Create a mechanism by which CI and CV jobs can be archived, but not deleted. Sometimes there is a job that is not used, but the history needs to be kept for some period of time.