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. Feature vs Release, Branch De-sync

    When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.

    Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.

    Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the…

    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. Sort or Filter Active CI Jobs

    Currently, there is no great way to filter out old/inactive CI jobs from the Active CI jobs. This poses a problem as there are situations where we have replaced CI jobs in the past, or created/disabled test jobs. Currently they clutter up the Continuous Integration Dashboard, but it would be nice if we could hide them so we don't have to delete them and lose their history.

    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)
  3. Schedule Delta CI Job to Run at Specific Time

    I would like the ability to schedule a Delta CI Deployment Job at a specific time. We have a requirement to deploy at weird times every once in a while.
    Code gets merged into our MAIN branch > Delta CI Deployment Job is disabled > click "run" on the job at specific time.

    It would be great if someone didn't have to wake up at 3am to click the "run" button.

    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)
  4. "Sync environment" automation

    On the pipeline, the action of "Sync environment" is currently a manual action. It could be useful to have an automation of this action (like the back-propagation) after each Production Deployment. This step is a little bit time consuming and can be easily missed. If we had an automatic creation of this synchronization PR on each CI Job it would make the processus more fluid.

    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)
  5. Branch Pattern Matching

    I want to use branch pattern matching to map CI Jobs to specific types of branches in my repository.

    main
    uat
    dev
    feature/*
    release/*
    hotfix/*
    chore/*

    Each of these branch types can have different CI Jobs associated with them. Or in the case of a chore/*, maybe I want those branches to Skip CI Validation because it is an ops branch that doesn't contain any Salesforce components.

    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)
  6. Sandbox Deployment With 0 Components

    Running a deployment into a Sandbox or Prod that has 0 components is a waste of time and resources.

    If a deployment has 0 components in it, either
    1. There's a problem because I was expecting greater than zero (so throw an error), or...
    2. I want to run tests, and theres a different command for that (I shouldn't be executing a deployment just to run tests).

    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)
  7. Pipeline CI jobs where deployment is disabled should capture validation job history

    If you have a Pipeline CI job configured to be Run Job = disabled; you can still promote PRs and run validations (which is great). But the validation job history is not preserved under the CI job. In fact, AFAIK, it can't be found at all except for the current promotion's vcalidation

    This would enable one to diagnose validation fails - perhaps due to problem analyzer automations. It would aid in communicating with support (as such validations could be shared)

    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)
  8. Local Metadata ignored if name collides across an unlocked package namespace

    Current Behavior:
    During PR validation of an lwc component named "utils", Gearset reports no changes and runs validation against target org with 0 components because there is a Namespaced Unlocked Package in the target that also has an lwc component named "utils". This can be seen in the "Problem Analysis Results" within the Validation Details for the PR.

    Expected Behavior:
    Gearset should not diff my local components against components that are behind a namespace. Even when those namespaced components are in an unlocked package. Perhaps Gearset should treat namespaced unlocked package components more like managed package components.

    This is related…

    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)
  9. Allow Quick Deploy when merging multiple PRs using Pipelines

    currently when merging multiple prs using pipelines the merged package validates and then the prs are merged, the resulting deployment then revalidates even though quick deploy is an option, can we use quick deploy when available like was enabled in the ci jobs?

    this would save time by avoiding double validation and make the feature more usefull.

    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. Automate creation of a release, which includes several stories

    Within pipelines, provide the ability to validate multiple Pull Requests (PRs) in one shot (i.e. release), so that this release could be deployed to production, for example, using Salesforce's Quick Deploy feature. This would be very handy when getting ready for a production release and I need to validate my release the day before. Thus, on the day of the release, I would simply Quick Deploy it.

    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)
  11. Copy reviewers to the cloned promotion branch PR in Pipelines (Bitbucket)

    When Pipelines creates a promotion branch and copies a PR that was opened in Bitbucket, it does not copy the reviewers. This means reviewers have no way in the Bitbucket UI to filter for PRs that they're assigned to review.

    Further, since all the cloned PRs are authored by the Pipeline owner, the lack of reviewers on top of that makes it quite difficult to visually differentiate between the list of open PRs, especially if you're both someone who creates & reviews PRs.

    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)
  12. allow field level granularity in CI Jobs

    Would like the possibly to set up a CI job that only syncs a sub-set of fields on a custom object. For example, we have an org to org sync where we want to update picklist fields but not autonumber fields. Currently we are running this job manually twice a day.

    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)
  13. Schedule deployment option for validation only CI jobs

    It could be good that time selection schedule option is available, makes release timetable easier to execute to target org.

    Currently user can only execute the pre validated package immediately.

    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)
  14. Approve Pull Requests from Gearset

    Currently you have to navigate from Gearset to Github using the link from the Pull Request to approve a Pull Request. While functional, this requires going to an external system for an important Git functionality. This also creates a bit more complexity for non-technical users. If we could approve PRs directly from Gearset, that would be awesome!

    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)
  15. On Create Pull Request, auto populate details with commit messages

    Similar to the way Bitbucket and GitHub work, it would be nice if the PR description was autopopulated from the commit messages (1 per line)

    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)
  16. Clone Problem Analyzer Templates

    With CI jobs, you may need to refine over time your Problem Analyzer templates

    However, there is no clone button and you have to carefully set up the new template (as edit-in-place is not supported when the template is already assigned to a CI job - at least that is what the in-app guidance tells you)

    So --

    a) Allow Clone from page app.gearset.com/problem-analyzer-templates
    b) Allow an easy way to assign the new template to all CI jobs without having to do each 1 x 1

    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)
  17. Revert with one click all changes from this PR

    Please allow reverting PR from lower environments. In mine example, we had a feature that went through develop and uat and was waiting in the pipeline to be added to release but the business changed its mind and canceled this whole feature.

    Please add an option that with one click we can revert PR and changes from lower environments.

    Image:
    https://www.dropbox.com/s/ohvymcs16p9n5ge/2022-06-30_14h10_44.png?dl=0

    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)
  18. to let us configure the default metadata filter by deployment pipeline configuration

    Can we please have a possibility to configure the "standard" metadata filter by each deployment pipeline project?

    I think it is currently preselected by the last used metadata filter from the standard comparison.

    As we usually have a specific metadata filter configured by deployment pipeline project, it would be great that we can configure each project with a default one..

    Thank you!

    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)
  19. Sort Validation Only CI Jobs

    In the CI Job page, you can sort the top-level jobs by different columns (Job Name, Source, Target, etc...) but you can't sort the actual instances of that job.

    We can get up to 30 PRs that are all being validated, and it would be nice to be able to sort them in some controllable way. It seems to rearrange them in whatever way it feels.

    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)
  20. Be Able to deploy Portal Sharing Settings and Organisation Wider Default Sharing Settings at the same time

    For example if attempting to deploy
    OWD permission Read -> Private, and Portal Sharing Set None -> Read. Gearset will fail validation due to SF complaining that Portal Sharing Settings cannot grant Read permission, since OWD is already giving that access.
    Though what SF sees is that Portal Sharing Set is trying to give Read when it already has that access.

    Therefore, if I want to make the deployment then I would have to do in 2 steps.

    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