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.

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 incredibly helpful to trigger Gearset comparisons, validations, deployments, etc. from an external source using an API. Our team uses GitHub for our VCS, which provides the perfect opportunity to:
1. design webhooks to validate changes in order to approve a Pull Request
2. design webhooks to automatically deploy changes to an org once the PR is approved.

Additionally, CI tools such as Jenkins, TravisCI, TeamCity, etc could use such an API to design complex builds that still employ Gearset, but use the external tool for additional actions outside of what Gearset provides for their CI features.

It would be great if we could configure a notification when a comparison completes. Sometimes comparisons take a long time!

My workflow is currently to deploy a change, browse to the deployment history to find my deployment, and immediately clone the deployment for another environment. It would be really nice if the clone button were available upon a successful deployment.

PMD 6 includes useful stuff like allowing annotations in the code to suppress warnings. It would be great to be on that version.

Stephen told me via the support chat that it wasn't simple to just upgrade, so I thought I would submit it as a feature request.

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.

When saving components into drafts, when validated, we would like the ability to be able to migrate the same components into new source and target orgs.

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

One should be able to edit all the fields on a CI Job, especially the source and destination fields.

If you create a new org, add an External Data Source, add External Objects, and deploy to a target (source control), you will get this spurious analyzer message:

"Some standard object fields which don't exist in the target organization are being deployed, which indicates they might use features not enabled in the target. You need to remove these from the deployment, otherwise it's likely to fail."

and all your external objects are enumerated, e.g.

Orders__x
Customers__x
...

These are not standard objects, and, as they are new, would of course not be in the target. Analyzer is being too "discerning"

Currently, when creating scratch orgs, the system automatically sets the expiration to seven days. However, scratch orgs can last as long as 30 days. Would it be possible to define the expiration number of days during creation?

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?

After setting up a CI job from a Salesforce sandbox to a Bitbucket repo, it looks like the CI job always runs a commit, even if there are no actual changes. It would be great to not have this happen to avoid having many commits where there are no actual changes.