It would be great if we can have the option to set and make use of 'deployment rules':

1 - receive an alert/warning message (in gearset/via email) right before deploying to a selected target environment, for instance - a production environment if certain pre-defined metadata types are included in the deployment.

use cases: a reminder to run all test when deleting metadata, a reminder to activate a flow on target environment after deployment.

2 - block a deployment in the following case scenarions:

a - if the deployment of certain pre-defined metadata types happens within a pre-defined timeframe.

use case: deployment of sharing rules during business hours

b - if certain pre-defined metadata types are not deployed by a certain role (e.g. team lead/owner).

use case: only team lead can deploy metadata for critical components (e.g. account and case triggers).

Criterias that may be used:

• metadata types included in the package
• keywords
• users
• date/time range
• target environment

When using pipelines, it would be helpful to have the option to automatically back promote changes through the pipeline. For example, we currently have a CI job that pushes specific changes that admins are allowed to make directly in production into our master branch. We then have a Github Action that automatically merges commits to our master branch to the other branches in the pipeline, so that everything is synced. However, in order to turn on pipeline, we have to turn off our automated merge action, because pipeline creates a bunch of PRs when the automation runs. This forces someone to go in every morning and back promote any changes pushed to master the night before. It would be nice if there was an option to do this automatically.

A good feature would be to have some setting that lets you declare when you should apply environment variables. Since right now it is applied automatically during manual deployments and CI deployments. Perhaps in the wizard when you configure deployments there should be some option there to declare if environment variables should be applied or not?

We have some Custom Metadata and Custom Settings that always need to be updated post-refresh based on the new sandbox instances and it would be useful to use environment variables to set these values and deploy them one-time without them being deployed in every manual and CI job.

When you go to the validation only CI jobs section within the Continues Integration part we usually have a CI job targeting a prod environment, you can see all validations succeeded and the commit attached to such validation, each CI job run contains 3 options:
View comparison
View Summary
Deploy

Then if the validation passed and the code indeed was merged from the feature branch to the master branch (Which would have triggered the actual CI job run), how would you be able to identify wether a merged pull request was deployed or not within gearset?

For me it's very helpful to be able to identify with kind of a "Deployed" label every CI Job run that was clicked on "Deploy" previously, So once you got more pull requests merged you will get to know pending to deploy ones with no need to check one by one or comment on the ticket.

Another option would be to be able to deploy and select the linked ticket before hand clicking on deploy, so you got another source of confirmation and at the same time you get the notes for the rest of the team posted on a jira comment.

We have 2 admins that we want to be able to create all of the CI and Pipeline Jobs, even if they don't have their own credentials in a particular Salesforce org. They have Deployment delegation, and can run compare and deploys, but not set up integration jobs.

This is then requiring us to either, provision extra licenses in each sandbox for our DevOps administrator, or have the developers create the CI jobs, which they are not comfortable with.

And, as we start the Pipeline Pilot, we would like to leverage all of the existing CI jobs, but, that is not possible, unless the same person that created them, creates all of the Pipelines.

As the owner of the CI job pipeline, I would like notifications when there are ongoing failures to the CI jobs that I select so that I do not have to continually monitor the jobs as a part of my day-to-day.

Acceptance criteria:

1. The current-state suite of notifications on CI jobs will still be available.
2. When a CI job has failed and the failure has not been cleared within X number of hours, the notification will be triggered.
3. Each CI job should have blocker notifications enabled separately.
4. Users will be able to select from SMS, email or both.
5. Users will be able to input a variable to indicate the number of hours that will pass prior the notification being triggered.
6. When the CI job blocker is cleared via a successful run, no notification will be triggered.
7. Organizations will be able to define the days of the week during which notifications should trigger.