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

1110 results found

  1. Add "View Validation in Salesforce" to your Github and Teams/Slack Channel messages.

    Our pipeline is utilized by some implementation partners that we do not give access to Gearset. They manage their changes that flow through the pipeline with GitHub and receive pipeline updates in a Teams channel. Both of these options have a message to view validation errors in Gearset but the partner teams cannot see Gearset. If these messages included the same "View Validation in Salesforce" option that lives in Gearset, they could be redirected to the Salesforce error page to help their troubleshooting faster.

    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. Invoke Run Anonymous Apex against target in CI Job

    Team,
    Can you please add Run Anonymous Apex option in a CI Job ?

    Step#1
    In this scenario from Developer's end they should add pre scripts in a.txt file and add post scripts in b.txt file in their Source Control

    Step#2
    How it should work
    - It should allow the CI job to run Pre and Post Deployment scripts
    - Pre Deployment scripts should be picked up from Source control a.txt file and Post
    Deployment scripts should be picked up from Source control b.txt file
    - Post commit the diff of commit should identify what are pre and post scripts…

    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. Ability to report on runtime in Gearset Reporting API and what metadata filters were used

    As part of showing the amount of time saved by using Gearset (and DevOps best practices), as well as the overall current utilization of Gearset across multiple teams and Gearset instances, being able to report on the Comparison, Validation, and Deployment runtime would be extremely beneficial. Also reporting on which metadata filter was used, if named and saved/accessible, in a comparison, validation, and deployment.

    This data could also be used to identify inefficiencies in the standard metadata filters used across our Gearset instances, and potentially identify clients not deploying smaller and iteratively in order to prove with data how that…

    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)
  4. Create releases in Pipelines not at final stage

    Right now you can only create releases at the last environment in a Pipeline. We'd like to have 2 stages so we have a true dry-run of deployment. Our pipeline is
    Dev > QA > UAT > Staging > Production

    Creation of the release branch before Staging would allow us to effectively cherry-pick what we want deployed into Staging as we get UAT approvals, do a test deployment where QA does a sanity/smoke test and have greater confidence when we get to our Production release.

    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)
  5. Add the package Name to the page, when the package is Opened

    Currently when you Open a package like a draft deployment, the Name of the package does not appear. There is a message in top L-H 'Comparison finished' which is not very useful. Perhaps the package Name could go here. It will reduce confusion as you will be able to tell which package you have open. Thanks.

    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)
  6. Allow users to select custom fields even if the object does not exist in the target

    Would be great if GS allowed to select custom fields when doing a comparison even if the object does not exist in the target. If I am pushing changes to a repository I might want to only include the fields I created/modified and not the whole object.

    14 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. Flow equivalent of Static Code Analysis-esque rules

    Code Analysis rules run against Apex in Gearset. As Salesforce development continues to rely on Flows as the main tool for declarative automation, it's becoming challenging to catch known inefficiencies, known issues, and discouraged usages. It would really set Gearset a part as a deployment tool to utilize issue detection or run "rules" against Flow metadata to call out potential issues or flows not following best practices to even prevent a deployment or commit from occurring.

    Examples: SOQL or DML in a loop, the number of elements for flows (prior to api v57) or general overall complexity, lack of Descriptions…

    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. Ability to automate deployment to a particular environment without manually promoting changes

    When there are multiple Salesforce environments in the deployment pipeline, like Integration, Qa, Stage and Production, we would like to have ability to automate deployments to a specific environment, without having to select PR and promote changes manually. Most of the times SIT/Integration environment will be used for Developers to be able to perform integration testing, where we do not want someone like a Lead to review and promote PR manually. It will be beneficial to deploy the changes automatically, as soon as someone creates the PR to the Integration environment.

    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. Update Deployment Functionality for Education Cloud Standard Picklist

    Currently, Education Cloud standard picklist field values are able to be deployed to production. However, the deployment lacks the ability to define active or inactive picklist values. The workaround is to manually activate and deactivate these values after deployment.

    This functionality was recently changed on 8/17/2023 for the Academic Session Season and Academic Session Type fields. Requesting the change to be made for all of these fields. Salesforce Education Cloud developer docs (https://developer.salesforce.com/docs/atlas.en-us.edu_cloud_dev_guide.meta/edu_cloud_dev_guide/edu_cloud_intro.htm)

    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

    0 comments  ·  Bug  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. Precision Deployments (available for Layouts) for all the meta data

    Precision Deployments for Layout is a great improvement, it would be great to have the same feature for other meta data, particularely for : Fields picklists, global value sets, List Views, Reports, Profiles, Permission Sets and why not Lightning Pages, now that the Dynamic Form is available for Acc, Contacts & Opp

    19 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. Expand the options for "Run job" times on the continuous integration job setup.

    Currently the "Run job" option has times for 1, 2, 4 and 24 hours. With international teams working on projects, it would be nice to allow for something like every 8 hours. That could either be a new set option in the list, or allow for a "custom" option. If the pipelines can handle between 1 and 24 hours, let us selection "custom" and input the hours for the job interval to run.

    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)
  12. automatic pipeline deployment on successful validation

    For Pipeline jobs, provide an optional feature (ability to toggle on/off) where if an Open PR has successfully validated on the target org, then auto deploy to target org. This is useful when propagating changes in downstream jobs. For example, once code review is done, a PR is merged into DEV by pipeline admin, but it should also automatically be merged and deployed into QA if the validation is successful.

    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

    0 comments  ·  New feature  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. Remove limitation of number of PRs to be added to a Release (Azure DevOps + Gearset)

    Gearset automatically adds all PR details for a release in description box (Azure DevOps PR) which has max character limit of 4000 and only 16-18 PRs can be added to a release because of it. When we add one more PR after the limit is reached then the next PR does not get added to the Release and we need to create another release for them which is not correct approach as other releases may have some dependency on 1st and thing may fail in production. We need a way to disable adding description to Azure DevOps Release PR so…

    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. Deploy Managed Custom Filters Globally

    When we associate a custom filter with a particular CI job, and then make changes to the filter, give the user the option to push those changes to all jobs (list them out) that use that named filter.

    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)
  15. Disable Pipeline Back-propagation for Static Environments

    We would like to have the option to disable the back-propagation in the pipelines for static environments or have more options to control how the back-propagation should behave, like not running the PR validations for these types of Pull Requests.

    When new changes reach the master branch, those changes should be pushed to the branch linked to a Salesforce environment. As it is today, the changes are back-propagated through new Pull Requests and because of the pipeline default config, the unit tests need to run which can block the sandboxes for some time depending on the complexity of the release…

    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. Include Pull Request title in the notification

    Hello GS team,

    Currently, the notifications from the pull request validations only include the PR number, I would like to request if it's possible to include the PR title.

    Current Sample: [Gearset] CI validation job Validation job for PR #11111 failed

    With the title in the subject of the notification, we can FW the results to the right teams automatically.

    Thank you!

    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. Pull Request Branch Filter/restriction

    Currently creating a pull request from the "Create pull request Screen" provides the user with a list of all the branches.

    The default of this seems to be based on the last location you had selected when you created your branch (This usually ends up being main). As we have a pipeline this is the last place you want anyone being able to create a PR into!

    It would be great if we could whitelist/blacklist a bunch of Branch names on this dropdown to stop users accidentally selecting main when creating a PR (for most users this would be one…

    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

    1 comment  ·  New feature  ·  Admin →
    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 a column for file sizes and show a warning message if over the limit (might happen deploying content assets)

    Recently when deploying a large amount of content assets, I ran into a issue where the deployment would freeze on caching metadata for faster comparison.

    Support told me the deployment size was too large and I broke it up into smaller deployments. I suggest adding a column with file sizes and perhaps a warning message if you exceed the deployment limits.

    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)
  19. Need to be made aware and/or given the opportunity to view the totality of the changes prior to deployment

    Heres what happened, we deployed the Metadata AND a ChatBot. As part of our deployment, we manually updated the metadatas to contain PROD relavent info (instead of ACC info that was pushed from ACC Branch)

    I also discovered that there were duplicate utterances in the Chatbot which we had to remove via manual DML deletes to ensure that the Data Model was built properly.

    Then, we wanted to deploy just a Field change, and did so by merging a PR containt just the Field Change into main in Azure. This, obviously, triggered a deployment and in that deployment, the metadata…

    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. Allow download of XML files from the comparisons page

    In some instances, we have to use the Metadata API to download XML files for analysis. However, the Metadata API is a pain to use. Even Salesforce recognizes this and suggests using a migration tool like Gearset to extract these: https://developer.salesforce.com/docs/atlas.en-us.246.0.api_meta.meta/api_meta/file_based.htm

    Since Gearset retrieves these files during comparison, it would be great if there was an option to download them to a zip file directly.

    Note: There is already a "Download Package" feature on the deployment page. However, we obviously can't add items to this page if there is no change between the orgs. So, if a similar feature were…

    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)
← Previous 1 3 4 5 55 56
  • Don't see your idea?

Feedback and Knowledge Base