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.

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.

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.

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!

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

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.

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

Remove Failing Items from deployment set: When a deployment fails with X errors I'd like the option to auto-remove those items from my deployment set. I may come back to them later, but I may also just want to see if I can do an intermediary deployment with the succeeding items. This is very relevant in org merge projects where there can be hundred of things to deploy across the spectrum of metadata.

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.

Allow us to save source/target pairings to make comparing/deploying less error-prone. Since I currently have access to multiple sandboxes and multiple git branches, it would be nice to be able to save/access my most used pairings for quick selection, instead of having to scroll through each picklist.

We'd like the ability to run static code analysis on all commits to a repo, regardless of the branch name. This would allow us to catch code quality issues early and up front, regardless of the branching model we use.

Example: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow (development is done in feature-* branches, so there's no one branch we can configure a CI job on)

Quite often an Environment needs to be refreshed, but every time it happens all the integration breaks as OrgId changes. Gearset can move metadata and data, which when made together can be a solution for sandbox refresh. Full copy sandbox sometimes takes days, GS will be able to it quite quickly.

When working inside of Gearset, it often alerts you to changes that have been recently made. It would be nice to have these as a separate, consumable, feed. We have a slack channel that we would like to pipe those changes to, for instance.

If you want to deploy new fields and field level security, I want to create a custom filter that hides all profile setting except of field level security and make that custom filter reusable.
Unfortunately RegEx only works on top level elements. In this case profile names. That doesn't make sense since that would hide field level security too.