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

31 results found

  1. Allow other Enterprise Users who do not own the CI Job to run it

    Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.

    46 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. Commit-by-commit deployment

    As you are giving an option to trigger the CI job based on repository commit, it would make more sense to only compare the source and target based on the commit items and consider the commit changes for deployment based on your selection of either new, modified or deleted and the comparison filter(which can be optional in this case).

    This will help in reducing the chances of overriding the changes of other teams working in a shared environment or an environment not in sync with the branch.

    There can be other scenarios where we maintain managed package items in the…

    43 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. Combine multiple deploy packages into one

    It would be nice to have the ability to select multiple packages in the deployment history, and clone all of them into one comprehensive deployment. This would help when there are multiple features moved at different times to a QA environment, but would like to move them all at once to Production.

    28 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. Rollback deployments made by CI jobs

    Manual deployments and change monitoring jobs can be rolled back. Add the same function to CI jobs in case it accidentally deploys something unwanted

    27 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. Allow CI to do a quick deploy

    Allow gearset CI to do a quick deploy either by default or via a setting on the Job definition.
    Our tests run for nearly 90 minutes and are currently run twice in succession causing a lot of frustration. Once when a PR is validated and then when it is merged and deployed.

    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)

    This functionality is now enabled automatically for CI jobs with the "validate pull requests targeting the branch" feature. This means Gearset will automatically try to quick deploy the package after the PR is merged meaning that tests don't need to be re-run. There is no need for users to change behavior and CI jobs will run and look as normal

  6. More granular control over CI job schedules

    Currently, a CI job that deploys from a Salesforce Org to another org or source control can only be scheduled to run at 4 hours intervals. Additionally, there is no mechanism of specifying when these jobs will run - instead, the job is scheduled randomly within the first 4 hours it was created and every 4 hours after that point.

    Providing a smaller interval (ex. every 1hr) and/or more granular control over the job execution time seems like a common sense enhancement.

    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. Add a Save As to Save Draft Deployment

    Add a Save As or an alternative way to create multiple packages from the same comparison. I have an existing comparison run and I want to stage the deployments, deploying some today and the rest next week. It would be more efficient to save both packages now as I am going through them, saving one for example as Dep120916.1 with half of my selected object and another one called Dep120916.2 with the remaining objects to be deployed later.

    13 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. To make it possible to abort started CI job on Continuous integration dashboard.

    At the moment, you need to wait until the comparison is finished and the deployment has been started and then you should go to the org to cancel running deployment. It would be useful to have an option to abort the CI job.

    11 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. offer the capability to exclude items in a metadata filter using a regex pattern

    If we can exclude certain things in the comparison filters, all other newly created things are automatically provided with the CI job that uses my comparison filters.

    For example, at the moment in "custom filters", if I select the type "custom object" and disable "all elements", I can filter and choose which objects we want to compare.

    -> We need the option to invert the filter. To be able to select the specific objects that do not want to compare and deploy (like "Not: regex: waste_ | QA_ | staging123_").

    11 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. Ability to run a Validation only CI job on a pull request - this will make pull request ready for deployment without error

    1. Developer creates a pull request to a branch
    2. CI job validates the pull request and notify in case of errors
    3. Developer corrects errors - CI job again validates the pull request and this time it is fine 4.Release manager merges the pull request to the branch specific to an org and CI job deploys without error.
    9 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. Be able to edit the CI sync frequency

    When creating new CI job from one Salesforce org to another, there is no way to edit the frequency of synchronization. It would be useful to make a change so that integration is done less often than every 4 hours

    9 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. Include/exclude individual metadata in templates by managed package

    The Include Managed Packages option right now is a global one-- and, while nice, that doesn't cover situations where you want some metadata of a Managed Package (eg. a Profile permission) to be included, but not others.

    Currently users have to laboriously deselect data related to Managed Package in certain areas (eg. Static Resources, Permission Sets, Custom Tabs) because it'll always fail to deploy.

    The ability to include Managed Packages for some metadata, but not others, in templates would solve this issue.

    9 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)

    With Gearset’s named filters, you can now configure exactly which metadata components are going to be included in a comparison.

    For the advanced use cases, you can also use regular expressions to define rules that, for example, include all managed components that match a certain naming convention.

    You can find the docs on our site https://docs.gearset.com/feature-guides/comparisons-and-deployments/custom-metadata-filters

  13. Create the ability to migrate components to new source and target orgs after having in a Saved Drafts.

    When saving components into drafts, when validated, we would like the ability to be able to migrate the same components into new source and target orgs.

    8 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. Be able to create a CI Job with the option to validate only (and quick deploy later).

    For the case where users have committed changes to a "master" branch, it would be useful to automatically run a full validation on the new commit in the Production environment. In that way, a deployment manager can review the changes and quickly deploy a validated package that has passed all tests in Production.

    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. Partial environment variable replacement and wildcards

    Some types of metadata, such as Platform Event Subscriber Configuration, have attributes identifying a user by username. As such, regardless of the value in the source environment, the value deployed to the target org must match the username pattern of that org.

    For example, if the value in the source repo is <user>name@example.com</user>, when deployed to a sandbox, it must be <user>name@example.com.sandbox1</user>. From sandbox to sandbox: <user>name@example.com.sandbox1</user> must become <user>name@example.com.sandbox2</user>. And finally, when going from sandbox to production: <user>name@example.com.sandbox1</user> to <user>name@example.com</user>.

    This could be solved by supporting environment…

    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)
  16. 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)
  17. Scratch orgs - Create a new scratch org with more than one package

    During the creation of a scratch org the system doesn't allow the installation of more than one package...so after create a scratch org we need to install manually the remaining packages.

    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)
  18. CI dashboard: Show commitId when job is in flight; Show queued commitIds

    On CI Dashboard page, a CI job in flight (deploying/validating) should show the commitId that triggered it (if any) PLUS show all pending CI jobs.

    Reason: If two developers are sequentially merging to a shared branch tied to the CI org (and webhook is setup to run immediately), then the first developer's merge starts CI job 1 while the second developer's job is queued.

    Yet, from the CI job page there is no way to even tell which commit to the branch is running (so as to clue the developer that his/her job is running vs queued. Commit message would…

    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)

    Thanks for the suggestion! When a CI job is running from git, the commit hash and the commit message is now visible for all git providers. In addition, for GitHub, Gitlab and BitBucket sources, a link to go to the relevant commit will be displayed.

  19. Allow users to specify when to apply Environment Variables

    A good feature would be to have some setting that lets you declare when you should apply environment variables. Since right now it is applied automatically during manual deployments and CI deployments. Perhaps in the wizard when you configure deployments there should be some option there to declare if environment variables should be applied or not?

    We have some Custom Metadata and Custom Settings that always need to be updated post-refresh based on the new sandbox instances and it would be useful to use environment variables to set these values and deploy them one-time without them being deployed in every…

    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)

    Environment variables will only be applied if its configuration as specified by the user (metadata type, item name, and a field for some types) matches the type and item name in the deployment package. 

    In all other cases, environment variables won't apply. 

    Added clarification in the Environment Variables config page: 

    "Environment variables will be applied automatically during both manual deployments and continuous integration deployments if the metadata item is included in the deployment package."

  20. Allow editing all CI Job Fields

    One should be able to edit all the fields on a CI Job, especially the source and destination fields.

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

Feedback and Knowledge Base