Help us improve Gearset

Welcome to the Gearset feedback forum. We love getting feedback from our users on how we can make Gearset even better.

Post your ideas and vote for others – let us know what’s important to you. We’re keen to hear about product improvements, new features, and bug fixes alike. We check this forum regularly and will keep ideas updated with their current status. If you need any further support, please contact us at team@gearset.com.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Add "View on GitHub" and "Create Pull Request" options when target is Custom Git Repository

    I've enjoyed using the view on github or create pull request options when my target is a github repo. However, when I use the custom git repository option which still points to my same github repo but doesn't require me to wait for all of my repo's to populate in the list, I'm no longer able to use them after a successful deploy. Please add "View on GitHub" and "Create Pull Request" options when the target is Custom Git Repository.

    3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  2. Report CI validation/deployment status to source control

    When a CI job is triggered by a commit to source control, please update the source control system with the result of the build - so that e.g. with Bitbucket we could see the build result from pull requests as at https://confluence.atlassian.com/bitbucket/check-build-status-in-a-pull-request-945541505.html

    3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  3. Link to test runs in Slack messages (or Slack messsage customisaton/templating)

    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}}..

    6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  4. Allow reauthorization of git/Bitbucket tokens used by CI jobs

    Currently, if the OAuth tokens used for a Bitbucket integration are refreshed, any existing CI job will not adopt the newly authorized token. In fact, there is no way to even edit the job to use the new credentials; the job must be completely deleted and created anew.

    However, in the case of Salesforce OAuth tokens, Gearset already has a Reauthorize button, along with facilities for re-associating the new credentials with saved orgs and saved CI jobs. Please enable similar reauthorization mecahnics and credential saving for other Oauth integrations, especially Bitbucket Server, so that CI jobs will not need to…

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  5. Eliminate unnecessary XML reformatting in git

    Currently, when gearset deploys XML to git, it seems to run it through a reformatter, which creates superfluous changes in git. These changes cause extremely large deltas, which are hard to read, increase the difficulty of merges and the likelihood of conflicts, and make working with any other metadata tooling (like SFDX) difficult.

    For example, here is part of a delta gearset commited for a profile.xml:
    diff --git a/force-app/main/default/profiles/Commissions.profile-meta.xml b/force-app/main/default/profiles/Commissions.profile-meta.xml
    index 8b11e6b7..3d640a50 100644
    --- a/force-app/main/default/profiles/Commissions.profile-meta.xml
    +++ b/force-app/main/default/profiles/Commissions.profile-meta.xml
    @@ -1,10 +1,27 @@
    -<?xml version="1.0" encoding="UTF-8"?>
    -<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
    +<?xml version="1.0" encoding="utf-8"?><Profile xmlns="http://soap.sforce.com/2006/04/metadata">
    + <custom>true</custom>
    + <profileActionOverrides>
    + <actionName>Tab</actionName>

    3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  6. If we move Jira ticket to status "Deploy" -> get the code from the repo ->deploy to destination ORG

    For example after Jira status "Deploy" is captured doing a comparison and deploying the changes will work.

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  7. This is related to webhooks feature in Gearset.

    Currently webhooks allow to trigger external job like jenkins job using webhooks. However its doesn't give any information related to this job whether its been called or not or pass or fail.

    Use case:
    The Jenkins job which I am triggering through Gearset calls my regression tests which runs on Jenkins server. I want to see the information like the Jenkins job has been called successfully and test results like number of tests run, pass , failed etc.
    Having this I can make sure the Webhook is working fine and know my test results in Gearset itself.
    It would be…

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  8. Possibility to deploy to another sandboxe when a ci job passed

    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.

    13 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  9. Allow sfdx project files for scratch org creation

    When creating a scratch org, allow us to select/configure a sfdx-project.json. This will allow for more complicated sfdx project to be deployed, i.e. multiple project folders, namespaces, ... etc.

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  10. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  11. Add support for incoming webhooks

    There's already a way to set up an outgoing webhook after a successful CI job run.

    It'd be nice to have a way for a CI job to have an incoming webhook from another service, such as ElectricFlow (a build platform).

    One use case would be for CI deployments to be dependent on external validation services.

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  12. Retain Link to JIRA Tasks When Combining Deployments

    Part of our release management policy is for all deployment to be associated with JIRA tasks. I noticed that when cloning individual deployment the association with JIRA tasks is retained. However, when combining multiple deployments, the relationship with JIRA is broken and as a result, we need to re-associate each JIRA task back to the combined deployment package.

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  13. Gearset API to externally trigger Gearset actions

    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.

    61 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  14. Improve Bitbucket Server integration for teams with large number of project/repositories

    ideally... gearset should not be hitting https://adlm.nielsen.com/bitbucket/rest/api/1.0/repos
    first. It should hit https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects to get a list of projects
    then allow the end user to select the project
    then https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects/{projectKey}/repos to get a list of repos on the project the end user selects

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  15. Ignore Unlocked Package Metadata In Comparisons

    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.

    2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  16. Possibility to deploy to another sandboxe when a ci job passed

    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.

    5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  17. Allow to add Custom fields to Source control without Account object in Source control. As we don't want to update existing Account object

    Allow to add Custom fields to Source control without objects in Source control. As we don't want to update existing objects in org.

    1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  18. Store formatted JSON in source control

    The SFDC metadata API returns some items types as JSON compressed to a single line. For example, this applies to Wave dashboards (.wdash files).

    Gearset neatly expands this to a more readable when visualizing and comparing.

    However, in source control Gearset stores them in their original one-line compressed format. As a result, when doing merging and conflict resolution at the source control layer, these items are impossible to handle, as *any* change (whether technically conflicting or not) results in a conflict from git's point of view.

    It would therefore be great if Gearset kept the expanded format for JSON data…

    2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  19. Show the latest commit(s) in the slack notification

    It would be extremely useful for the development team to see the last set of commits which were deployed via an automated job, so that if it breaks it is easier to tell what broke the build or if it is successful what the org has been updated with.

    2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  20. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

← Previous 1 3
  • Don't see your idea?

Feedback and Knowledge Base