Idea is to have the Delta CI for Validation only Job, so the as well, so the validation process will become faster .

The option of validating a PR in the deployment job does the same task, but is comparing too many items of metadata and it is taking too long.

When setting up the filters, I would like the ability to do a Select All on just the filtered items so that I don't have to manually select each one of them. This would be a huge time saver.

It would be nice if we have the select all option in the deployment history to select multiple packages to combine in one go and deploy as one package into target.

I would like to see a change to the metadata filtering in general.
Filter management has become a important part of our devops process as we seek to lower our comparison timing.
Instead of having it at the bottom corner of the compare screen, move that section to the middle of the compare screen.
In addition, add a side bar specifically for filters that allows you to edit or delete them as well as change the sharing between personal and team. I have example screenshots for suggested layout changes here: https://faef.box.com/s/frse8jnvqsxbl8ue05x641j3wlga1quy

Ability to Export Validated Packages from Grid, like Deployment History.

This feature would allow Enterprise user with Role"Owner" to Delete Validated Deployment by Other Users. The reason for doing this is that there could be packages created in error and this would allow release managers who are typically owners to cleanup.

Once you create a regex filter in your your Metadata Filter, you can't select it and edit it. You have to delete and re-enter.

This is especially useful when working with CI job filters

When you stop licensing a feature, there could be all sorts of cruft in the VCS that is otherwise challenging to remove using normal Gearset tools.

Example: We stopped licensing LiveAgent but our VCS is full of references to LiveChatTranscript and other CustomObjects used by this feature. This is particularly apparent with sub-elements of Profile

It would be cool if Gearset repo cleaner could detect when standard objects no longer available in the source org of the compare would be considered as deleted and all refs to those standard objects would be repo-cleaned.

We'd like the ability to view the number of changes that were deployed from the Deployment History table view so that we can quickly scan the list of recent deployments and identify certain deployments using that additional information.

On the deployment history page, the column widths are fixed. If you have a value in the "friendly name" column that's over a certain character count, it gets truncated automatically. there is a tool tip to see the full value by hovering, but if you use consistent naming standards for naming deployment packages, this can result in having to hover over many package (i.e. rows) to find the one you want.

if making the column width customizable isn't possible, then making the "friendly name" column character limit longer would be a good start!

When you delete a managed package from VCS by deleting its <InstalledPackage>, Gearset should look for all traces of that managed package in VCS and delete those files/update the metadata

The <InstalledPackage> file identifies the namespace - eg. SomePkg, and Gearset should be able to remove files that start SomePkg__ as well as delete/edit metadatablocks within other files that reference SomePkg__c.

It is extremely tedious to remove managed package metadata from VCS otherwise; especially if the customer opted to put a lot of managed package metadata in VCS (perhaps by accident)

Lets say multiple vendors are working on different environments and done the deployment across all the lower environments using their own Gearset. But coming to the production org. internal team will be performing the deployments using internal Gearset. So Instead of recreating the deployment draft again, it would be very useful internal team can reuse the draft created by vendor in different Gearset environment.

This could be automatically prefixed to friendly name of the deployment.

Sth like "000035"

Could be a simple counter (that I see you have implemented "This is your NNth deployment...").

If the autonumber would pop up automatically then I would not need to figure out a reference and type it myself.

Currently, info that potentially could be used: datetime (too long) , url (way too long)

Currently successful deployment notifications send every success to the specified addresses. Having the ability to specify the source would eliminate the unnecessary notifications to those addresses. We have a use case in which we only wish to send notifications for successful deployments to our production source.

It would be great to see the chosen data hosting option for an account in the 'My Account' area. Without it security audits will not be able to verify what setting was chosen and will have to rely on documentation held elsewhere.

Currently, if your deployment fails you have two options:

1. Click "back to results"
2. Click "new comparison"

Going with option 1 means it needs to re-load the comparison and then click next and re-run all the analyzers again which can take a varying amount of time depending on the size of the comparison/deployment.

In situations where the deployment failed, but the fix is to change something in the org manually - it'd be great to have an option to simply "retry deployment" from the failed deployment screen and skip the various screens and re-loading.

Be able to delete a comparison run with wrong filters or just keep the latest comparison