When we pull down a version between our local and staging environments. We would like to also automatically pull in the testing data from another project.

As one of the things we are trying to setup is taking a version from Prod then running GhostInspector through our core flows. Ideally every 4 hours we take a backup from metadata + locked down actual data. Then run tests against it.

Currently, Enterprise users can create monitoring jobs on sandboxes, so that they may be notified when a sandbox's metadata changes. It'd be great to be able to perform the same monitoring action against source code repositories (GitHub!).

An example use case would be detecting when undesired metadata types enter into the repository. This is important because CI jobs will fail on certain metadata types, so we want to ensure that they never make it into source to begin with. Additionally, our business has decided that some metadata types should never be captured into source.

If I have a managed package object in Git, Gearset does not recognize it as managed package code in its comparison to a Salesforce org. This is a problem since it may not recognize a change if a custom field has been added to the managed package object.

I understand the Draft Deployments are snapshots from when they were created or last refreshed. Is that right? Please show these fields on the Draft Deployments page.

would be cool to be able to "ignore" certain differences... e.g. encryption. So if encryption is enabled in a Production Org but not in a Sandbox (not sure if Encryption is possible for SBs), you have a difference for every custom field <encrypted>true/false</encrypted> which is really irritating.

When user clicks on test run details, Gearset defaults to the successes tab. But no one clicks on test Run details to see successes; they want to see failures. Default tab should be failures, especially if non-zero

Saves user a click and supports DWIM - "do what I mean" when clicking Test Run Details

PMD support is great, but it would also be useful to be able to have a set of custom rules for my team

e.g. we have a code library of classes that they ought to use instead of coding their own solutions every time. Some of these cases could be spotted by a PMD rule, so it would be great to be able to add my own rules for this.

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.

Implement public key authentication for source control.

Allow Gearset to generate a public/private key pair, and expose the public key for use in authentication to source control.

We do the majority of our management via Jira and have it linked to Bitbucket and our test system so that we can manage everything via Jira. It would be great to extend the current integrations to more intelligently link the package to Jira tickets and the corresponding Bitbucket code and then push back to Jira the deployments in a more Jira friendly manner e.g. potentially creating/updating a Jira release for the deployment.

Can you create a master-switch deployment option? It would be similar to how this operates: https://sfswitch.herokuapp.com/

The issue is that this master switch does not always work with managed packages in production orgs.

So a way to automate the turning off/on of Validation Rules, Process Builders, Flows, and Triggers.

Use Case: We are building a new app and have significant data migration to do. It would help to have a master switch to turn off processes in PROD, deploy date, then, flip the master switch back to turning processes back on.

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

I have so many connections and jobs, is it possible to have group them (in future release?)

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...

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

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.