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.

I suggest you ...

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  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.

    16 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  2. 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.

    3 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  3. She the commit message with the Commit ID on the CI History Screen

    The CI Job History Screen would be much more useful for me if it was able to show the commit message on the commit that triggered the CSI alongside the source commit ID.

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  4. 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…

    17 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  5. 1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  6. Allowing data deployments in CI jobs

    Allowing data deployments in CI jobs. So that configurations in third party apps and B2B Commerce can be deployed as part of CI.

    2 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  7. Add the option to purge on delete

    The metadata API has a boolean option to "purge on delete", i.e. permanently erase deleted items rather than just moving them to the recycle bin. This option is not exposed in Gearset currently, but rather hardcoded to "false". For CI scenarios in particular, it would be extremely helpful to be able to specify that this option should be set to "true" for deployments.

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  8. Support parallel testing during CI job

    CI jobs use metadata API to deploy and run tests. The tests run serially. As such, CI jobs can take many minutes to execute

    As an optional configuration for a CI job, and only if the CI is run against a non-PROD org...

    1. Deploy metadata using Metadata API
    2. Run tests using Tooling API (parallel testing)
    3. If tests fail, use MetaData API to rollback the deployment

    Ideally, this can shave off 50% of the CI job time

    2 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  9. Ability to add custom trigger points to trigger CI from source control

    At the moment the tool allows you to only kick off CI jobs when a branch is updated.
    This is actually limiting the capability of the tool in itself,
    because services like Bitbucket allows you customize trigger points, as to when they should ping the webhook;
    such as the creation of pull request, merging a pull request.

    The two trigger points mentioned above are specifically very important because you would want to run validation CI jobs on the creation of pull request or when the merge completes so that you can actually ascertain if your branch compiles.

    Based on an…

    6 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  10. Add an auto-save feature while building deployment packages

    As Gearset is run through a web browser, if the browser happens to freeze while a package is being built, you don't have the opportunity to save it as a Draft Deployment. An auto-save feature would allow someone to pick up where they left off, or when the last auto-save was done, without having to start from scratch.

    32 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  11. CI job status "deploying" - add dateTime

    UX suggestion:
    On the CI jobs page...

    Currently - you see last run dateTime followed by "deploying...." if a job is currently in progress

    Suggestion: Add the dateTime when job started so user can gauge when job should finish and set expectations accordingly

    For example, in our shop, a CI job should take around 20 minutes - but if you can;t tell when it started, you can't gauge when it will finish and plan your work accordingly

    2 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  12. Allow deployment of PROFILE only

    The main reason we considered Gearset was issues with deploying profiles. Half the object settings, if not more, don't come over with change sets. When attempting to use Gearset to ONLY deploy a profile, we had the same issue. So, what's the point of using GS then? When I talked with one of your technical resources he did mention that was not a common use case. I would think it would be for large organizations like ours (over 3500 employees). We may want to spin up a new profile and just deploy that with no app or any other features…

    8 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  13. 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

    6 votes
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  14. 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).

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  15. Run test in parallel using scratch orgs

    CI job that run all test takes ages. Can we use scrach orgs and test suites to run test in parelell in multiple orgs?
    https://developer.salesforce.com/blogs/2018/06/running-tests-5x-faster-using-sfdx-and-heroku-ci.html

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  16. allow for the ability to "lock" a metadata filter in for a CI job so that the CI job has any changes to filter.

    Currently, the CI job takes the current metadata filters settings but does not used the updated settings. You have to re-add the filter back to the CI job. If checked on the CI job, the job would use the current filter's latest changes rather than the ones it was created with.

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  17. Extend the ability to add and delete in a single deployment to all metadata types

    We just came across an issue in which we were deploying an HTML email template that had been moved from one folder to another in the source environment.

    When deploying, only the delete happened on the first deploy. I needed to do a second deploy to handle the addition.

    While probably not a common case, it's certainly important as the initial deployment reports that the addition was successful.

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  18. Create a Master-Switch Only deployment process

    Can you create a master-switch deployment option? It would be similar to how this operates: https://sfswitch.herokuapp.com/

    The issue is that this master switch does not always work with managed packages in production orgs.

    So a way to automate the turning off/on of Validation Rules, Process Builders, Flows, and Triggers.

    Use Case: We are building a new app and have significant data migration to do. It would help to have a master switch to turn off processes in PROD, deploy date, then, flip the master switch back to turning processes back on.

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  19. Add Run all tests except .... configuration in CI job

    Our CI jobs take way too long (1000+ tests) despite heroic efforts to use ApexMocks. As our org contains a bunch of unmanaged packages with known class name prefixes, and these constitute at least 10% of the total tests; we could get back 10% of our life if we could exclude these from the "run only your tests"

    For example, we would want to exclude running any tests in classes that start with "fflib" and "sfab"

    A variation of this would be to run a specific testSuite and it would be our responsibility to keep the testsuite up to date

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
  20. Allow (restricted) editing of source XML to add deployable properties that can't be fetched via Metadata API

    related to: https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/14808303-allow-source-metadata-to-be-customised-prior-to-de

    Example:
    It is impossible with OOTB Gearset to deploy an autonumber field with a starting number and optional populate existing rows. Why? Because the SFDC Metadata API as of V42 doesn't allow fetching of these two properties of the CustomField object:

    <populateExistingRows>true</populateExistingRows>
    <startingNumber>1</startingNumber>

    Once in source, they'll deploy just fine to the target org. Note that changesets support this feature.

    The workaround, which is to deploy to target branch and then edit target branch is sort-of-OK but it would be nice to modify this in the source. Of course, if you Refreshed Comparison, your edits would be…

    1 vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Flag idea as inappropriate…  ·  Admin →
← Previous 1 3
  • Don't see your idea?

Feedback and Knowledge Base