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. 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)
  2. 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)
  3. view deployed components live

    Show live the components deployed during the running of a CI/CD Job.

    Like:
    deploying class abc.......
    deploying class xyz.......
    deploying lightning Component abc.......

    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)
  4. allow a method to set up default branches.

    I frequently deploy from our on premises GitLab repo. It would be great to have the ability to set the default branch it goes to. It would be one less click for repetitive steps

    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)
  5. Display a custom name in Salesforce when deploying from Gearset

    When we deploy a change to one of our Salesforce orgs using gearset, the name that is displayed in the "Deployment Status" in Salesforce is an ID. It would be helpful to display the name that we entered in Gearset instead of the ID so that we can easily identify the changes when looking at them in Salesforce

    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)

    Hi,

    We have recently investigated adding this feature again, but unfortunately Salesforce still don’t seem to support being able to display custom names via the Api (or it’s a feature that’s not well documented). There are requests for adding this ability via:

    https://success.salesforce.com/ideaView?id=08730000000cJdxAAE

    If the situation changes then we’ll certainly revisit this. We’ll keep this post opened for other users to also add their votes but it’s currently out of our hands as to when or if it can be added.

    Regards,

    The Gearset Team

  6. Enforce code coverage limits on CI jobs

    Please set it so that we can force a code coverage check on deployments (including CI). I'd like to verify on the lowers before going through to production. Might be able to do this with test cases but should be able to on deployment.

    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. Be able to switch the direction of a comparison/deployment

    Sometimes we need to reconcile changes on an object between two orgs, where some of the changes have been made in Org1 and some in Org2. Having set up metadata filters, compared and deployed required changes from Org1 to Org2, it would be nice to be able click a button to switch direction to then deploy required changes from Org2 back to Org1, without having to go through the whole process of setting up a new comparison.

    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)
  8. Feature Request: Deployment Blocking Based on Daily Unit Test Job Status

    Currently, Gearset lacks a feature to block deployment CI jobs to the respective environments when the associated daily unit test job fails. Implementing this feature would be advantageous in ensuring that appropriate testing quality gates are established to prevent changes from being deployed in the event of test failures. This enhancement would significantly improve our deployment integrity and testing processes.

    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)
  9. Slack notifications for non-CI deployments

    We use slack for monitoring which is great. We'd like to have the ability to setup more slack notifications for non-CI jobs.

    Additionally, we'd love to see deployment starting notifications as an option as well, to allow our greater insights into when it's coming.

    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)
  10. Add option to "run tests if X is present" on CI jobs

    At the moment Gearset only offers an "all or nothing" option ("run all tests"), which is safer but completely ruins minor and cosmetic deployments (because it then takes half an hour to deploy even the smallest, inconsequent change like a Layout change) or "apex or nothing" option ("Default") which does allow for minor deployments to go through.. but also anything that's not Apex, which is dangerous because what if I'm deploying other automations like Flows? these changes would go un-tested.

    At the very least an option for "run all tests if Apex OR Flow is present" sounds mandatory. But ideally…

    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)
  11. 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)
  12. CI Job History - Show what CI runs were manual and who triggered the manual run

    It's nice that the CI job history shows the source commit link for the auto triggered deployments from Github merges, but for visibility and transparency it would also be good for users to see when a job was triggered from a manual run and what users ran it.

    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)
  13. Load Balancer for CI validation

    would be nice to have possibility to configure 1 source (git branch), but multiple targets (sandbox), so gearset would have some "load balancer", which would distribute the validations into sandboxes, which are not busy. Its taking too much time from developers to wait for their validations to finish.

    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)
  14. The option to auto-populate FLS/permissions for selected fields/objects/classes

    I'd need an option to auto-deploy FLS for items i've selected in one click.
    Sometimes the amount of changes is huge, and finding and clicking Permissions for selected items one by one is not a deal. For sure, it's possible to select all Permissions in Source org, and let the wizard to deselect Permissions for missing items in target, however that the result does not usually correspond to items that are in package.

    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)
  15. See Continuous Integration Deployments in the Deployment History tab

    List deployments resulting from a CI job on the Deployment History tab along with manual deployments.

    We currently deploy metadata using both manual and CI jobs and it would be convenient to see all deployments in the same list (for debugging, reporting, monitoring).

    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)
  16. Allow "Rollback" if you have a user within the same org

    Rollback currently requires the user who did the deployment to enable "Deployment" user access. Instead, it would be helpful if I could use my own user, within the same org, to do the rollback.

    This would be helpful if the individual who did the first deployment is unavailable.

    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)
  17. Automatic sandbox updates option

    The new sandbox updates process is really convenient - you can see all the updates a sandbox needs and apply one or more. However it is still very much a manual process to start it. We have a team of engineers and each one of them has to constantly go and trigger the update process manually whenever an update becomes available.

    It would be really nice if there was a switch for 'Automatic updates' i.e. whenever it is turned on, the updates are applied automatically during off hours.

    Of course if an update fails the engineer would receive an email…

    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)

    This is currently planned for later this quarter and next.


    Users will have the option to:

    • Bulk update selected dev sandboxes
    • Automate developer sandbox updates; they will be immediately tried as and when ready


    If users want to automate dev sandbox sychronization now, they can use CI jobs to deploy changes from their desired source of truth - this comes with some risk of affecting work in progress though.

  18. Precision Deployments for Lightning Web Components

    It is very much required to have Precision Deployment for LWC components as it is common to have multiple developers working on same LWC

    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)
  19. Grouping developer sandboxes in Pipelines - back-promotion to a group

    Team,
    Currently Gearset Pipelines only offers the option to connect a developer sandbox group to a single downstream environment. While back-promotion to a group isn't available yet

    Could you please enable 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)
  20. Give CI/CD Users the option to use a shared webhook or a new one in BitBucket

    Gearset recently updated its automated webhook setup for new CI/CD jobs to use a shared webhook. For my team, we have configured each webhook for validation jobs to only run on PR creation/update and deployments to only run on branch pushes. By forcing the new jobs to a single shared job, it causes PR merges to trigger validations alongside the deployment (Which is time-consuming and needless).

    Also, as my team has many legacy webhooks for our existing jobs, when we add a new job it seems Gearset randomly assigns it to an existing webhook. For our recent deployment-only job, 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)
  • Don't see your idea?

Feedback and Knowledge Base