In most of Tech industry deployment lifecycle, all code or config changes are ideally pushed into production only from a FullCopy Sandbox(Commonly Known as Staging Environment).

It would be very good to have a feature in GearSet App which if enabled shouldn't allow user deploying data from Dev/DevPro/Partial Sandbox into Production Org.

Allow user to directly create a change set without doing the comparison. If user has a list of items that needs to be migrated then allow the user to add items and skip comparison step.

have a way to dump a csv of the description of objects. i need to find a way to see what fields are encrypted.

Being able to configure which problem analyser results to use in CI jobs.

For instance, we can’t deploy any changes to managed packages because the problem analyser will ignore them (even though we have components from a managed package that we can modify and deploy without issues), that would help to reduce our manual steps during deployments.

Currently one has to pick dates individually, if one has 30 + dates to select, this can be massively simplified if one could select a date range.

When deploying email2Case i am unable to choose particular email2Case that i need to deploy and end up choose all the email to case settings. Needed feature to deploy this selectively.

For CPQ Deployments add an "Upload from CSV" feature where a user could upload a file with specific External IDs across multiple objects to tell Gearset what to migrate in a single click.

For example, the user could list the Object API name in Column A of the sheet and the External ID in column B and then Gearset would parse this and create a Data Deployment based off of those records specifically. This would be incredibly useful for any CPQ deployment where you need to only deploy specific records not the entire object!

There are times when I'm in an email thread with other developers and I want to share a list of metadata that I'm trying to deploy via Gearset. It would be nice to have a button after a validation or deployment (failure or success) that copies in plain text a list of everything in the deployment. The list not only has the name of each metadata, but also the type of metadata it is.

Currently, if you have a saved filter being used in CI jobs, any edits/changes to that filter are not reflected in the CI jobs that use said filter.

It'd be great if we could isolate filters for CI jobs so that we could edit CI job filters that would then affect every CI job they're being used with instead of having to edit every job and re-select the filter whenever a change is needed.

If the deployment package (especially if target is PROD) contains ONLY Apex classes annotated as @IsTest, then coerce (w/ user confirmation) the deployment to just run those test classes.

This helps avoid errantly clicking the default Deploy and waiting 20-30 minutes for all tests to run. If only test classes are being deployed, by definition, the underlying code hasn't changed and all tests DON'T need to be rerun.

Allow for the upload of a local file which includes the destructiveChangePost.xml, destructiveChange.xml, and destructiveChangePre.xml files to do destructive changes.

Filters are shared by default. However, if someone changes the filter, I cannot tell what has been changed, who made the change or when it was changed. Ideally, I'd like a version history for each filter.

How about a default BitBucket repository on the popup page that appears when you clone a package (under “Deployment History”)?

In Manage Custom Filters dialog, Gearset should link to

a) https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm
b) a Gearset list of Metadata API-supported but not yet GS-supported metadata types

saves devops person wondering why certain metadata can't be deployed

Hi Gearset,
I would suggest you to provide an extra option where we can select weekly ,daily or monthly schedule jobs in Unit Testing Jobs.

Thank you,

A very good feature for metadata management tool like gearset will be an helper which allow to identify metadata not used or not properly configured.
For example this concurent have this feature : https://www.metazoa.com/snapshot-use-cases-org-cleanup-and-optimization/

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.

Over the past 2 days we ran multiple comparisons between salesforce orgs. Nothing was changed in the target org but some fixes were applied to the source org in order to make the deployment successful. A lot of time would be saved if we had the option to compare the source org to a cached copy of the target org. In this case, the source org was finishing very fast, especially when we used the local file comparison.