When using a git repo with a SFDX folder structure + package/xml (in the /manifest folder) gearset dos not take into account elements in the package.xml when checking the option (filter with package.xml)

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.

As of now, if you have deletions enabled in a CI job, everything is deleted. It would be great to be able to specify which metadata types you want to include in the deletions since normally you won't need to delete all differences. This would be specially helpful to remove Apex classes and its permissions from profiles.

create an option to have chained deployments so complex deployments can be broken down and sequentially deployed or slaves can be ran

allowing for multi staged deployments under one CI job

When metadata is retrieved from Salesforce the order of child nodes is not guaranteed and results in false-positive changes when committing to version control. Usually this will be something simple like workflow actions/criteria appearing out-of-order which can be compared manually. However, recently we've noticed entire profiles being committed with *every* permissions element out-of-order, resulting in a change set with ~20k lines where the *actual* change is impossible to visualize.

Gearset should provide a feature to 'order' child XML elements alphabetically by name in order to provide consistent commits to version control and eliminate false-positives.

Show live the components deployed during the running of a CI/CD Job.

Like:
deploying class abc.......
deploying class xyz.......
deploying lightning Component abc.......

I want to send the automatic report generated at the end of the deployment to my client. However, I want to personalize it with the logo of my company or add additional text.

We have CI jobs that fire on commits to a source control repository. At the moment, there is no way to email the specific individual who made the commit that prompted the deployment, so we have to notify everyone involved in the project whenever a deployment fails. If we could just notify the individual who made the commit (plus the deployment manager), it would reduce noise considerably.

Please add this feature.

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.

I've enjoyed using the view on github or create pull request options when my target is a github repo. However, when I use the custom git repository option which still points to my same github repo but doesn't require me to wait for all of my repo's to populate in the list, I'm no longer able to use them after a successful deploy. Please add "View on GitHub" and "Create Pull Request" options when the target is Custom Git Repository.

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.

When a CI job is triggered by a commit to source control, please update the source control system with the result of the build - so that e.g. with Bitbucket we could see the build result from pull requests as at https://confluence.atlassian.com/bitbucket/check-build-status-in-a-pull-request-945541505.html

At commit to branch, Gearset reorders large chunks of the XML file. This causes additional deltas (seen in the hundreds of lines) and merge conflicts.

Add during problem analysis:

Remove the "run as specific user" completely from the dashboard prior to deployment (set the options to "Run as logged-in user"). Deploy, then change it back to whatever you need. Based on https://developer.salesforce.com/forums/?id=906F0000000DCJPIA4

Did Compare two org after changing Permission Set. Removed Access to Record Type. Gearset did show no difference.

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!