As Gearset is run through a web browser, if the browser happens to freeze while a package is being built, you don't have the opportunity to save it as a Draft Deployment. An auto-save feature would allow someone to pick up where they left off, or when the last auto-save was done, without having to start from scratch.

It would be great to have more control over the diff process - particularly to be able to ignore whitespace changes.

If I've made an actual function change to a class, and also auto-indented it, then it would be a lot easier to see the important change if I could hide the whitespace-only changes.

Having the ability to suppress whitespace-only changes on the list of changed objects would be really useful, too.

We have both admins and developers working within our SFDC environments.

Admins typically deploy across environments, so being able to create a CI job to keep the repo updated with these org-to-org changes would be ideal.

The metadata compare and deploy is outstanding and works well. What would save configuration and release engineers even more time would be an object data compare / sync. Sometimes, salesforce releases may only require a data migration. Hopefully, this feature will get a few upvotes from the community as well.

In order to support a development pipeline (e.g. Dev Environment -> Staging Environment -> Production) allow Metadata from the source Org to be modified before deployment to the target Org.

e.g. I have a RemoteSiteSetting in source that points at https://dev.example.com and in my staging environment I need this to point to https://stg.example.com

Allow those filters we can save to be shared amongst our team!

Sometimes a user may forget to add in a commit message before deploying, so the history in our source control is "no commit message" which is not editable. Can we add a feature to be able to turn on marking commit messages as a requirement for deploy?

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'

Would like to be able to quickly select the custom objects and standard object custom fields AND only the related metadata items to make then function correctly (permissions, layouts, field level security, etc..)

Then we could go back and migrate all the process automation stuff - workflow rules, flows, trigger, etc..

It always starts with the data schema first. We need a quick way to see what is different between two orgs and get that synced first

Ability to pause a CI job. This would allow the CI system to keep our sub environments (stage, dev, beta) updated all the time, but when we want to develop on one of them we could then pause the CI job so our changes don't get deleted. Then once we have deployed the changes to prod we can reactivate the CI job to keep things in sync.

Manage users on "My Team", so we can activate/deactivate users and then save on licences that are not used until reassigned.

Support automated webhooks into Jira Cloud for:
- Creating a new ticket when automated tests fail
- Updating existing tickets with deployments using the standard Atlassian smart comment format "[TicketID,...] some comment"

It would be nice to have the ability to select multiple packages in the deployment history, and clone all of them into one comprehensive deployment. This would help when there are multiple features moved at different times to a QA environment, but would like to move them all at once to Production.

Right now if a deployment fails in Gearset, it doesn't show up anywhere within Gearset; it just sends you an email. It would be nice to have a place to view failed deployments and retry them (maybe it only failed because the environment was locked), just like you can with successful deployments in Deployment History.

When deploying, there's a pain point when we want to specify tests to run. It would be nice to have an option to only run test classes that are included in the deployment. Automatically identifying which test classes are in the deployment package should be fairly straight forward:
`grep -ri @IsTest ./src/classes`