I have automated test jobs post about failed tests to our Slack. I want the posted Slack message to include a direct (though maybe shortened) link to the "Test run details" so that when we see Gearset telling us about some tests starting to fail I would be one click away from seeing a view of failed tests the message is talking about.

Next/bigger step would be a way to shape the Slack messages ourselves. The most basic templating setup where I could write my own Slack message with some placeholders like {{instance_name}} or {{failed_tests_link}}..

Currently Data Deployments only allow filtering on
[FIELD] = [VALUE]

It would be beneficial to be able to include other logic operators such as:
NOT EQUALS
LIKE
IN
GREATER THAN
LESS THAN

etc.

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.

Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.

Include the name/id in the deployment detail page within Salesforce in the Gearset deployment report so we can trace and match those details to a deployment run in Gearset.

When comparing Custom Objects that contain the managed custom fields there is no way to suppress the managed custom fields. The fields would show up in the comparison results even without being requested. The problem analyzers then highlights and remove these managed custom fields.

This is cumbersome when repeated and makes finding genuine differences we care about more difficult.

From the problem analyzers, it sounds like Gearset is able to identify the managed custom fields. Therefore could there be an option under [Include managed package] in the Custom Filters that allows the suppression of known managed fields in comparison results?

1. Developer creates a pull request to a branch
2. CI job validates the pull request and notify in case of errors
3. Developer corrects errors - CI job again validates the pull request and this time it is fine
4.Release manager merges the pull request to the branch specific to an org and CI job deploys without error.

When configuring a CI job, we need an option to set a deployment to another sandboxe when the deployment or test classes run successfully in the current CI Job.
Ex: when a push to a branch on VCS triggers a CI job to deploy to a sandboxe like QA (with test classes run), we also have the possibility to set an auto deployment to staging sanboxe when the the job on QA passed successfully.

Currently, metadata from Unlocked Packages show up when comparing against an org. This leads to duplication of metadata in source control repositories (correct DX package repository and incorrect monolithic, "happy-soup" repository).

Using the Package2Member Object (Tooling API), it is possible to deduce whether or not a metadata item is part of an unlocked package. Therefore, it should be possible to ignore some or all unlocked packages (or any Package2 package), in a similar fashion to the way Gearset filters allow inclusion or exclusion of managed packages.

Allow complex filters and child relationships on filters for data loading. For example, filter the Account to only load if the Owner is an Active user in the system.

I need to set up monitoring against an org that is owned by a user who is no longer active or licensed in the system. It would be incredibly helpful to be allowed to transfer ownership of these orgs between users, rather than requiring someone to delete the org and recreate it under the different owner.

I'd like to be able to export a snapshot of all the metadata from my production org (include all components) to my git repository by clicking a single button.

After every release, it's worth taking whole metadata export from the org to git for the next/on-going releases.

For now, we have to create a couple of metadata projects to export the metadata to git, which is a tedious job and takes a lot of time.

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.

Creating a visualization of the DevOps process removes the need for separate Visio diagrams or visual aids to represent the process. Also by creating this feature, you could allow for a drag and drop type feeling to represent CI Jobs, Data Deployments, Comparisons, etc. Users who may be new to a DevOps environment would pick up the process quicker allowing them to quickly adapt to the tools and this type of deployment mentality.

**Current State:**

A few devs have work in their individual sandboxes that are ready to be pushed to the higher .dev sandbox org

1st Dev deploys work to .dev

2nd Dev deployment fails because org is locked

**Idea:**

A few devs have work in their individual sandboxes that are ready to be pushed to the higher .dev sandbox org

1st Dev deploys work to .dev

2nd Dev deployment is queued up, 2nd Dev will be notified via email/browser when queued deployment has started

In the new UI for Validation to view failed test classes error messages you must click into each failed class to view the details.
--
The previous UI showed "part" of the error message within the table. This was extremely useful in identifying all of the "unique" errors that are occurring.
--
IE: If 58 test classes fail from "4" unique issues -- then in order to determine that you may need to click into all 58 test classes or fix one at a time --> refresh --> validate.
--
This is just a time save feature.