Gearset's ability to send notifications to Slack is great. I'd like a similar ability to send notifications to Atlassian's Slack alternative - Stride.

Macros deserve to be added to source control yet there is no way to do this with Gearset:

1) Data feature (paid add-on) doesn't deploy to/from source
2) PRO/Enterprise can't source/target deploy Macros because it is not available with the Metadata API.

Since macros represent some debugged logic, managing in source control makes sense. Curiously, SFDC has chosen to make Documents available via Metadata API but not Macros

Right now, Gearset is down and we cannot use it. It would be good to have a trust.gearset.com site that shows what is going on and what the team does to fix the issue...

When pushing work flow rules and associated actions, if you do a compare with only workflow, then gearset prompts an error indicating that the target objects do not exist in the destination and that the rules should be removed from the package for the deployment to be successful. In this case, it told me Account, Event and Opportunity do not exist in the target. Including other metadata from the referenced fields resolves the issue.

For example; when adding new custom fields, you generally have to add the permissions as an additional line item to the deployment. Having a checkbox or something that will have gearset automatically add the permissions associated with the metadata currently in the deployment list would speed up the process. Users should also be allowed to deselect lines that were automatically added.

It would be cool if the custom deployment configuration could be driven from a Pull Request . For example, in GitHub, the Pull Request knows which files were changed and approved. Why not use that list to instantly populate a comparison to create a deployable manifest to go from source control to org?

Our CI jobs take way too long (1000+ tests) despite heroic efforts to use ApexMocks. As our org contains a bunch of unmanaged packages with known class name prefixes, and these constitute at least 10% of the total tests; we could get back 10% of our life if we could exclude these from the "run only your tests"

For example, we would want to exclude running any tests in classes that start with "fflib" and "sfab"

A variation of this would be to run a specific testSuite and it would be our responsibility to keep the testsuite up to date

With GDPR, companies are required to provide justifications for all data that they collect. In Salesforce this means being able to identify why all fields in the system exists, categorize fields as PI, and provide business justifications. The ability to keep a list of current fields in a production instance of Salesforce that includes alerts when new items are added, or ability to sync that list out to another tool like Smartsheet, where other business users like a legal team would have visibility, would be incredibly useful.

For example, deployments to a production environment should only come from the master branch of our git repository

When connecting a source code control system, quite often an integration user account is used that may also be used for other parts of the enterprise. Please allow admins to restrict the available repositories and branches so that users can only run comparisons for the branches they should actually have access to.

Use case:

1. Deploy from source to target
2. Some testing (or possibly PR review) in target requires fixes to be redeployed from source to target

Currently, you either do a new Comparison or clone the Deployment and re-enter the source and target. In either situation this is tedious.

Why not add a "Redo" button on the Deployment History that uses the same source/target? Place it next to the Clone button?

Or, in the Clone button, default the source and target to the same as the selected Deployment? (which would also be useful)

If your source is Local files, and you do a Compare to some target, and then realize the source needs to be amended before re-comparing, your "training" is to clock "Refresh Comparison" button.

This executes but does not ask you to upload new source files so essentially nothing happens.

User should be given option to upload new folder/zip.

The XML that comes from Salesforce is weirdly bundled together. When changes are made it's really hard to reconcile two branches in source control when merging.

When comparing, Gearset nicely decomposes changes into smaller chunks. So instead of putting that back into the usual XML, an option to store that "internal format" and even just stick it as JSON or similar.

After all - it'll be Gearset reading it back in to compare to an org next time, and smaller changes will be easier to merge as they won't conflict inside horrendously large XML files

It would be nice if you broke up the settings into smaller subcomponents. For example the Security settings would be more useful if you extract out the password policy changes so we can pick and choose what Security settings we need. I thought of this concept similar to how you break up profiles into sub component. This could get noisey in the list of changes so an alternative to that could be to bundle it under components like how CustomObjects work.