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.

It would be nice if there was a quick way of init'ing a new sandbox that matches either what was in source control or an existing sandbox.

Currently, I need to run a comparison between the existing source and the new sandbox and then I can try the deploy, but it would be nice if the compare step was not needed and I could simply say 'overwrite what is in the sandbox with what is in the specified source'

This would save us time duplicating regex statements for the new job

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

Sometimes we need to reconcile changes on an object between two orgs, where some of the changes have been made in Org1 and some in Org2. Having set up metadata filters, compared and deployed required changes from Org1 to Org2, it would be nice to be able click a button to switch direction to then deploy required changes from Org2 back to Org1, without having to go through the whole process of setting up a new comparison.

Better error reporting when CI jobs fail. Many times I open a failed job and there are no errors reported.

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.

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 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

Allowing data deployments in CI jobs. So that configurations in third party apps and B2B Commerce can be deployed as part of CI.

Currently CI jobs can only validate PRs into a regular org. So if you have multiple PRs raised to that branch then you have to wait as they each run one after the other. If we could validate into separate Scratch Orgs instead then all the PR validations could run in parallel and it would speed up validation

It's nice that the CI job history shows the source commit link for the auto triggered deployments from Github merges, but for visibility and transparency it would also be good for users to see when a job was triggered from a manual run and what users ran it.

It would be nice to control when we want tests to run based on the type of changes in the triggering event for CI. Something like only run test classes on update of Apex Classes, Flows, Workflows, and Objects.
This is a bit of a patch for not having test classes fully optimized but would be helpful with orgs who have lots of profile and layout changes.

I'd need an option to auto-deploy FLS for items i've selected in one click.
Sometimes the amount of changes is huge, and finding and clicking Permissions for selected items one by one is not a deal. For sure, it's possible to select all Permissions in Source org, and let the wizard to deselect Permissions for missing items in target, however that the result does not usually correspond to items that are in package.

When you are pushing a project with sfdx, there is no compare, sfdx just push the whole package.

It will save a lot of times.

Allow a basic find/replace to run against files before final deployment.
Examples: a username that would work in the sandbox that does not exist in production and we need to change it. Or deploying to a packaging org required a modification due to various namespace issues. Other tools have a means to do this in one way or another.

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.

CI jobs use metadata API to deploy and run tests. The tests run serially. As such, CI jobs can take many minutes to execute

As an optional configuration for a CI job, and only if the CI is run against a non-PROD org...

1. Deploy metadata using Metadata API
2. Run tests using Tooling API (parallel testing)
3. If tests fail, use MetaData API to rollback the deployment

Ideally, this can shave off 50% of the CI job time

Use case:
1. Compare and deploy from repo-R/master to org A
2. Clone deployment from repo-R/master to org B

Unfortunately, when the clone deployment displays the dialog "Reuse Deployment Package"...

a) When you select GitHub, the dialog doesn't default the repository to Repo-R but instead displays a picklist of all possible repos the running user has access to (in our case that is 100+)
b) Better would be to remember in cookie the repo the developer last used and default to that choice so scrolling through 100 items is not necessary.

Rollback currently requires the user who did the deployment to enable "Deployment" user access. Instead, it would be helpful if I could use my own user, within the same org, to do the rollback.

This would be helpful if the individual who did the first deployment is unavailable.