As of now, if you have deletions enabled in a CI job, everything is deleted. It would be great to be able to specify which metadata types you want to include in the deletions since normally you won't need to delete all differences. This would be specially helpful to remove Apex classes and its permissions from profiles.

create an option to have chained deployments so complex deployments can be broken down and sequentially deployed or slaves can be ran

allowing for multi staged deployments under one CI job

Show live the components deployed during the running of a CI/CD Job.

Like:
deploying class abc.......
deploying class xyz.......
deploying lightning Component abc.......

I want to send the automatic report generated at the end of the deployment to my client. However, I want to personalize it with the logo of my company or add additional text.

We have CI jobs that fire on commits to a source control repository. At the moment, there is no way to email the specific individual who made the commit that prompted the deployment, so we have to notify everyone involved in the project whenever a deployment fails. If we could just notify the individual who made the commit (plus the deployment manager), it would reduce noise considerably.

Please add this feature.

It's not convenient when a validation fails, to then download the excel file of the the validation errors, view in separately form Gearset, and then go through the list of metadata I'm trying to deploy and try to uncheck each one that failed the validation. It would be nice if Gearset did that for me.

This will allow to deploy Case.settings without getting this deploy error:
EmailToCaseRoutingAddress[Info]: emailServicesAddress is a read only field and cannot be changed

I am able to deploy profile components and permission sets separately. But the permission set assignment is part of salesforce SOAP API and I couldn't deploy the same using GearSet.
Kindly provide deployment options not only for Metadata API, also SOAP APIs

When we deploy a change to one of our Salesforce orgs using gearset, the name that is displayed in the "Deployment Status" in Salesforce is an ID. It would be helpful to display the name that we entered in Gearset instead of the ID so that we can easily identify the changes when looking at them in Salesforce

For every release, we have at least 700-1500 or more components to be deployed and adding all those one by one into gearset is a lot of manual effort which might sometimes not be entirely accurate. It would be great if there is an option where we can upload an excel or csv with all the component names and gearset would just create the package for you. It would save a lot of time and effort and reduce manual errors.

When a developper deploy a new feature on a sandbox it will be perfect if the deployment can be auto deploy on a branch git (and copy the deployement note, etc).

Today I use a CI job backup on the sandbox but we lost the deployment comment + the updates granulartity.

We could use also the "Clone Button" on the result deployment page but it's lost time to relaunch the comparison and the different step etc while we want exactly replicate the deployment.

I was informed in my slack integration today that my CI job failed with an error message of UNKNOWN_EXCEPTION: admin operation already in progress See https://app.gearset.com/failed...

I would like to see Gearset automatically identify this type of error as something different than a metadata error and then retry that CI job 3 times over the next 90 minutes (for example). It would be fine for it to stop after those 3 successive failures.

Is it possible to set time Instead of running CI Jobs every 4 hours or 24 hours.

I frequently deploy from our on premises GitLab repo. It would be great to have the ability to set the default branch it goes to. It would be one less click for repetitive steps

The CI Job History Screen would be much more useful for me if it was able to show the commit message on the commit that triggered the CSI alongside the source commit ID.

It would be great if there is an automated approval process to deploy the code to higher environments. If there is a button "Submit for approval", and an email sent out to approver. that we can setup. once approved, a CI job need to run and deploy the changes to next environment.

1. Developer creates a pull request to a branch
2. CI job validates the pull request and notify in case of errors
3. Developer corrects errors - CI job again validates the pull request and this time it is fine
4.Release manager merges the pull request to the branch specific to an org and CI job deploys without error.

It would be useful to see the meta data filter used on the deployment successful report

Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.