It would be great to see when a team member last logged in on the user account management page. It would also be great to see like a report or extension on the user page where we can see user usage information. Like number of compares, deployments, etc.. may when last compare was done.

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.

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.

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)

As feature has moved from pilot to beta in Winter '20 release, looking for support in differencing and deploying the new 'PermissionSetGroup' metadata type.

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

Better error reporting when CI jobs fail. Many times I open a failed job and there are no errors reported.

In order to make deployments more repeatable between orgs please allow a way to save the selection of deployment analysis suggestions an d list of test classes with a package. With a large package it can be difficult having to document or remember the same selections used in deployment to UAT org for Production deployment.

It's not convenient when a validation fails, to then download the excel file of the the validation errors, view in separately form Gearset, and then go through the list of metadata I'm trying to deploy and try to uncheck each one that failed the validation. It would be nice if Gearset did that for me.

Currently:
We have to define a single fixed source branch in a CI job, when it has a Git-Source.

Desired:
Option to say "use triggering branch". It should use the branch, where current commit-hook-call comes from.

It should allow Pipelines to test also all development branches e.g. with "Validation only" CI-job.

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.

Please add a link to the test results as part of the notifications sent to Microsoft Teams. The integration with Slack already includes the link so it would be very helpful to have a similar integration in Microsoft Teams.

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

Ability to specify test suites when deploying/validating apex classes. It would be easier when there are a large # of test classes involved with a deployment