Rather than splitting jobs into Validate and Deploy and ordering alphabetically, allow custom ordering (drag and drop, or custom grouping) in order to maintain logical job sequences including a mix of deploy and validate jobs.

The ability to delegate access to a scratch org without extending access to the related production environment would be helpful. We have situations where we need developers to build new ideas in a scratch org but do not want to extend the access to the production environment

Inline Editing of metadata
In order to make our deployment successful we had to download the package, modify the version numbers on the flow definitions, and then compare the local package to the target org. It would be very helpful if we can edit the metadata XML in the UI so we can fix the version numbers.

Hi Gearset😍
Love your deployment product!

We are using salesforce as a ticketing system - any chance you are planning to make a connection to Salesforce records like you did for Jira or Azure?

I would love the have the option to do some things automatically after a deployment, for example:
Attaching the deployment report to the ticket
Updating Status field
Update Environment Field (based on target org name)
Posting a chatter post about the deployment

Thanks!

Hi Team,

Please add checkbox for validated package as same as deployed ones. that way I can combine package even for validated one's and deploy.

Currently IP ranges defined in, say, a sandbox get carried over to the target environment (another sandbox or Production), when Profiles are migrated.
In some cases this means, these means these IP ranges may have to be manually removed from the target environment.
It would be great, if there were an option to exclude these IP ranges from the selected Profiles.

The comparison screen is great to help admins and declarative users see the changes they made. However, it still requires them to know which metadata to pull based on changes they made.

Source tracking in Sandboxes is in beta and would alleviate this concern.

https://help.salesforce.com/articleView?id=sfdx_setup_enable_source_tracking_sandboxes.htm&type=5

If Gearset could leverage this functionality (potentially leveraging SourceMember object or storing .jsons to track last modified times as local projects store) it would make the complete process easy to use for all alike (pull metadata, select diff, deploy).

https://ej2.syncfusion.com/vue/documentation/drop-down-list/filtering/
Much like the above, when searching through many fields it can be tedious

It would be very useful to have a Global Search feature within Gearset. This would be used to search the contents of all metadata objects.

My use case is that sometimes a string has been hardcoded inside a function. The only way to find the function that contains the string is to manually trace through the code. The global search would indicate the function that contains this string.

Another benefit would be to track dependencies for metadata objects that don't support dependency tracking. For example Aura Components, we could search for the component name.

Add support for bash scripting. This is one of the most powerful features of Jenkins and something that would make a huge difference in Gearset.

Use Case:
When deploying items from one Org to another I need to filter by newly created items as well as latest modified items. So there is a use case here to add the Created By and Created On columns in the Compare window.

Or the ability to add predefined columns into the view.

When combining packages it would be very nice if there was a 'Select All' checkbox.

Please add WebStoreTemplate as a metadata type

an additional layer of security and convenience would be to enable Gearset login (that is, login to Gearset) to be done from an enterprise's SSO solution. We use Duo but Okta and others should be supported.

Just like we can login to Salesforce from our enterprise's SSO , we should be able to login to related apps in our suite of enterprise tools via SSO

We want to restore certain fields instead of all data into Salesforce

Please include columns for the components Label and API Name along with the Item Type and Display Name when exporting to CSV.

Use Case - We use the Export results as a formal Deployment Log that we sharing with a Client's project team. In that log, we include the component's Label, API Name, and metadata Type. Most recipients of this Deployment Log are unfamiliar with the API Name which may not even closely match what the Label is. Having both in this Log would greatly enhance this understanding.

Thanks in advance!

due to deployment limitations with salesforce destructive changes destructive changes dont necessarily reflect branch to org so these deltas are being marked as differences even though there is no way to fix other than manually in the org. these should be marked as a separate difference type for easier filtering.