Skip to content

Help us improve Gearset

We love getting feedback from our users on how we can make Gearset even better. Post your ideas for improvements, new features, and bug fixes alike, and vote for others – let us know what’s important to you.

If you need any further support, please contact us at team@gearset.com.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

189 results found

  1. Possibility to validate a feature branch as a whole without having to select the Metadata type

    It looks like the current validation jobs setup in Gearset needs the Metadata Type to be explicitly selected to perform the validation. This should ideally be optional and there should be a capability to just validate everything that is there in the feature branch against the target org. It's really annoying for us that we have to select the Metadata Types to be validated.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Option to set and make use of 'deployment rules'

    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:…

    7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. Include Deployment Name on Continuous integration dashboard

    On the Continuous integration dashboard, specifically in the Validation only CI jobs section, there is no way to associate a validation job with the deployment dashboard in Salesforce. We have a validation only job set up to run tests on PRs when they're created. If we get a handful of them all at once, there is a long list of validation jobs running, but we can't tell which one is the one that's actively running. There is no link between the job in gearset and the job in salesforce.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. See when a commit validation was deployed or not (For CI validation Jobs)

    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…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Pipeline automatic back promote

    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…

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. Customize CI job commit message

    When a CI job pushes changes to source control, it always uses the message "CI deployment from job <CI job name>". It would be very helpful to be able to customize this message.

    5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Transfer ownership of an Org Monitoring job

    Transfer ownership of an Org Monitoring job:

    We are a consulting firm and a project team often changes during the life of a project. Right now if we have an org monitoring job tied to a project and the owner of that job is moved off the project we need to create a new job and perform a manual comparison.

    It would be great if instead of all these manual step we could just change the owner of an Org Monitoring job.

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. Additional text countries

    I'd like to see a few extra countries added to the text messaging option on scheduled deployments. My team works with resources in different regions.

    Brazil +55
    India +91
    Philippines +63

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Manually Delete Metadata after CI job runs

    We don't want the CI job to delete metadata, so we've unchecked that box. However, when a CI job runs that would have deleted data, we'd like to be able to select from the job history, review what would have been deleted and elect to deploy the deletion manually post CI run. We can re-run the comparision from Compare and Deploy, but having this action tracked within the CI job history would be more convenient, and would allow the history for the target org to be contained in the same thread.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. CI Deployment on a Schedule

    We would love to schedule a deployment from GitHub source to a few sandboxes at the end of each 2-week sprint.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. Notification of unresolved CI job failure

    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…
    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. Allow Deployment Notes to be editable post-deployment

    Allow Deployment Notes to be editable post-deployment. Our team uses very specific notes for auditing purposes, and being able to edit them post-deployment would make that process a lot easier for our teams.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. Allow the creation of CI Jobs against Salesforce orgs that we are delegated to, instead of needing to be owner.

    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…

    5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. Granular "difference types to deploy" on a metadata level

    In the CI job, we would like to have the ability to specify on a metadata level if we want to deploy new items, update items and delete items. There are examples of metadata where we always want to delete and others where we don't want to.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. Add option to provide exact time in case automatic deployment

    We need to set exact time for automatic deployment. We need this option for example for night releases for specific client. This is important for international clients that works in different time zones

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. Make metadata filters easier to use when you want to "include all except X,Y"

    For CI jobs, it is not uncommon that you want to include all elements of a given custom metadata type except specific elements

    Today, you need to have two entries - an include all (".*") expression and an exclude expression. For users who are not regex savvy, this is too complicated.

    We should have "All", "Named", and "All except Named" at the top level so simple check boxes can be used.

    This is particularly useful for CI jobs (whose purpose is to sync VCS w/ org) - you want to sync most everything except a few items - like Sites…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. Ability to differentiate between scheduled metadata deployments from validated packages and non validated packages

    Under Deployment History

    1. All scheduled packages should appear. This is not the case today, validated packages that have been scheduled appear under validated packages with a Scheduled Date but not under Deployment History

    2. Scheduled packages should have a link to the appropriate Validated package if any.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. Add an option to disable Problem Analysis for CI

    When running CI jobs, we can create a problem analysis template to control what potential problems can block a deployment.

    For deployments from SF orgs to Git, many of the problems being analysed are just irrelevant (e.g. users don't exist in the target, because the target is not Salesforce).

    Although some options can be switched off via templates, the list is not comprehensive. So, it would be great to have an option to switch off everything, or a built-in template of "no analysis".

    When production is the source of truth, we just want all the metadata to get copied into…

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. Add the ability to order/chain overnight jobs

    Gearset offers various automated jobs that run overnight e.g. Org Monitoring Snapshots, CI Jobs, Unit Test Runs.

    it would be great to be able to set an ordering on how those run for any particular org. For example, a natural order for the night jobs may be:

    1. Monitoring Snapshot
    2. CI run
    3. Unit testing

    This means we have a backup before making any potential CI changes and the unit tests show the results after CI. It would also allow us to make sure that the jobs don't clash.

    Ideally, we'd be able to do this without just specifying exact times to…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. For failed CI job runs, develop a way update to the job status

    When for whatever reason, jobs can get job stuck in status "Deploying".

    The real deployment task is already successfully finished in the org, so I would expect that the status of the CI job would be "Succeeded".

    I was assured that in 24hrs the status of the job will automatically reset, but can we have also a way to force an update to the CI job manually?

    Note: The "Cancel running CI job" button is visible and clickable, but doesn't do anything with this stuck CI job.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?

Feedback and Knowledge Base