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. Queue Deployments

    **Current State:**

    A few devs have work in their individual sandboxes that are ready to be pushed to the higher .dev sandbox org

    1st Dev deploys work to .dev

    2nd Dev deployment fails because org is locked

    **Idea:**

    A few devs have work in their individual sandboxes that are ready to be pushed to the higher .dev sandbox org

    1st Dev deploys work to .dev

    2nd Dev deployment is queued up, 2nd Dev will be notified via email/browser when queued deployment has started

    2 votes
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)

      We’ll send you updates on this idea

    • Be able to sort/filter Validation Failures during Deployments

      Like how it used to be, when I could see all the Validation Failures on one screen. I'd just Snipping Tool them, head Back to Results and fix them, quick and easy. Now the Failures are scattered within the Successes with no way to filter or sort them.

      1 vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)

        We’ll send you updates on this idea

        Hi,

        You can now sort the validation failure columns in the table.

        Did you know that you can export the results table for either failed validated components or if tests fail to a csv file using the bottom at the bottom of the page? That may also help with being able to do more advanced filtering.

        Regards,

        The Gearset Team

      • Deployment Notes Persist on Failure

        When a deployment fails, deployment notes are sometimes wiped, and it is laborious to retype them - sometimes, I'll copy and paste to Notepad before deploying because I know I'm going to have to type them again. Notes should persist, or at least be configurable, from one comparison run through successful deployment.

        1 vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)

          We’ll send you updates on this idea

        • Export PMD rulesets/configuration as xml file

          This would allow us to configure our rules in Gearset and then apply the same ruleset during our local development. Until we can upload our own xml config file, please add the ability to export the Gearset rules instead.

          see related idea: https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/34668196-allow-pmd-to-be-configured-by-uploading-a-xml-file

          2 votes
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)

            We’ll send you updates on this idea

          • add the ability to run static code analysis against an org or source control, simply click refresh button to re-run it and see results

            This will give you a "run code analysis -> see results -> fix issues -> push to source control (or an org) -> repeat" workflow.

            1 vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              Signed in as (Sign out)

              We’ll send you updates on this idea

            • 2 votes
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                Signed in as (Sign out)

                We’ll send you updates on this idea

              • Offer to push components that passed validation even if some items failed

                For large payloads (thousands of artifacts) it can be tedious to try to resolve a few minor issues when 99% of the package will deploy successfully. Having a feature to push stuff that passes validation would be helpful. Included in this in the deployment summary and deployment reports will be a count and list of items that failed validation and were omitted from the package so they can be investigated

                5 votes
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  Signed in as (Sign out)

                  We’ll send you updates on this idea

                • Better Targeted Static Code Analysis Feedback Surpression

                  Currently, if I want to suppress errors from static analysis, the suppression seems to be all-or-none at the class level.

                  I would prefer to suppress only the specific errors when they happen.
                  (e.g. in the method or in the line.)

                  1 vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    Signed in as (Sign out)

                    We’ll send you updates on this idea

                    Hi!

                    Our static code analysis is built on PMD. Currently, the only error suppression that works with Apex code in PMD is the `@SuppressWarnings` annotation. (This was introduced for Apex in PMD version 6.0.0). As you say, you can suppress all rules, or specific rules, at the class level, but can’t make more fine grained suppressions, unfortunately.

                    There are other methods of suppressing errors within PMD for other languages, but these don’t currently work with Apex. We’ll keep an eye on future versions of PMD to see if they introduce new methods of suppressing warnings for Apex code.

                  • New analyzer check - changing field type on a custom metadata type (mdt) field

                    Turns out the following can't be done:

                    Change the type of a xxx__mdt.Foo__c (e.g. from Number to Text)

                    While the Force.com UI doesn't let you do this directly, you can do indirectly by deleting the Foo__c, then adding it back with a new field type. Your sandbox is a-ok with this

                    But if you try to deploy, SFDC won't let you deploy and you get this error: "This field is on an object that doesn’t support field type conversion."

                    Gearset Analyzer could check this by comparing source to target and give you a nice warning. Would save the developer/release manager…

                    1 vote
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      Signed in as (Sign out)

                      We’ll send you updates on this idea

                    • Allow PMD to be configured by uploading a xml file with rules

                      We use PMD locally in our IDEs to analyse during development, and the whole team shares a rule file in xml. It excludes the ones we don't like and configures other rules.

                      We can configure Gearset to do the same through the UI, but I'd rather be able to just upload the file, then I will *know* they are the same set of rules.

                      3 votes
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        Signed in as (Sign out)

                        We’ll send you updates on this idea

                      • Adjust dependancy on managed package versions for Apex[Class|Page]

                        We've found when developing classes against managed packages the class ...meta.xml includes the package version numbers. Problem is these are fixed to the exact version installed (e.g. 9.4, 9.3 etc. example below)

                        But then if the managed package is upgraded Salesforce, in its infinite wisdom, doesn't update these so when you come to deploy next time you have to go and manually update all the version numbers - or if you have a different version in another sandbox (to test the newer one) same thing.

                        Seems like something a cool deployment tool could handle and offer to fix up on…

                        2 votes
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          Signed in as (Sign out)

                          We’ll send you updates on this idea

                        • Allow custom rules in PMD

                          PMD support is great, but it would also be useful to be able to have a set of custom rules for my team

                          e.g. we have a code library of classes that they ought to use instead of coding their own solutions every time. Some of these cases could be spotted by a PMD rule, so it would be great to be able to add my own rules for this.

                          3 votes
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            Signed in as (Sign out)

                            We’ll send you updates on this idea

                          • Add a note against individual components in a draft deployment

                            While comparing two Org's for differences and saving the 'Draft deployment':

                            1. Files that I'm sure and fine with the differences and happy - so tick them.

                            2. Files that are important to be deployed but I am yet to discuss those differences with some peers from team (dev / support). I would like to mark these (or / and) comment against these - with some useful notes (ex: impact or risk analysis related notes). Once these are discussed, I can then tick them - indicating I am happy to deploy these.

                            Once I mark the files as either 1…

                            2 votes
                            Sign in
                            Check!
                            (thinking…)
                            Reset
                            or sign in with
                            • facebook
                            • google
                              Password icon
                              Signed in as (Sign out)

                              We’ll send you updates on this idea

                            • Avoid Analyzer suggesting to deploy a workflow's Sobject when such SObject and all referenced fields exists in the target

                              Use case:
                              1. Deploy from source to target a changed Workflow (from active to deactivated)
                              2. Target already has all of the workflow's referenced components (fields used in filter criteria, fields used in Field Update)

                              Analyzer will tell you "Add the following to the deployment" and something that looks like:

                              Deploy All
                              - object.WfName
                              -- object and its subcomponents
                              -- object and its subcomponents
                              -- object and its subcomponents

                              Since the object is already in the target as are the subcomponents, this message is alarmingly misleading and could inadvertently lead to deploying an object not yet ready.

                              The above message…

                              1 vote
                              Sign in
                              Check!
                              (thinking…)
                              Reset
                              or sign in with
                              • facebook
                              • google
                                Password icon
                                Signed in as (Sign out)

                                We’ll send you updates on this idea

                              • Provide the option to skip problem analysis

                                Sometimes during a complicated deployment I need to try a few different strategies to get things to work. For example, I may need to just send up one piece or set of metadata up first.

                                The problem is, each time I do this, I have to wait for problem analysis to complete, which takes a couple minutes. Normally during a deployment I do want problem analysis to run, but if I want to quickly send up a single object, I have to wait a few minutes while Problem Analysis runs, and the time waiting adds up.

                                Maybe a quick deployment…

                                2 votes
                                Sign in
                                Check!
                                (thinking…)
                                Reset
                                or sign in with
                                • facebook
                                • google
                                  Password icon
                                  Signed in as (Sign out)

                                  We’ll send you updates on this idea

                                • Error while deploying dashboard component using Changeset / Gearset / ANT

                                  This is a common error received during deployments:

                                  Error: Metric, gauge, or table dashboard component missing indicatorLowColor attribute (line 70, column 33)

                                  This is a suggestion to Gearset team for there feature Deployment analysis if they would pick this error in advance before deployment.

                                  Observation: This issue occurs when the Dashboard is created in Lightning. (I cannot confirm though)

                                  Resolution:

                                  Downloaded package.xml and component

                                  Basically, after I pulled the dashboard metadata from source org, I opened it and found the
                                  <componentType>Table</componentType> tag, and right under it I added this:

                                  <indicatorHighColor>#00716B</indicatorHighColor>
                                  <indicatorMiddleColor>#ffb75d</indicatorMiddleColor>
                                  <indicatorLowColor>#C23934</indicatorLowColor>

                                  After this change I managed to deploy everything…

                                  1 vote
                                  Sign in
                                  Check!
                                  (thinking…)
                                  Reset
                                  or sign in with
                                  • facebook
                                  • google
                                    Password icon
                                    Signed in as (Sign out)

                                    We’ll send you updates on this idea

                                  • Field Tracking Analyzer message is misleading

                                    If source org includes a new custom field with field history tracking enabled TRUE, the deployment analyzer reports the following when deploying to target org:

                                    'Fields with history tracking enabled cannot be deployed before it is enabled on the object. You should remove these history tracking changes from the deployment'

                                    Specific use case was object OrderItem

                                    1. Analyzer can clearly detect if field history is enabled on target org object (which it was) - message is spurious.

                                    2. Analyzer can arguably detect that target org's limit (20) will be exceeded by the deployment of the selected custom fields (which could…

                                    2 votes
                                    Sign in
                                    Check!
                                    (thinking…)
                                    Reset
                                    or sign in with
                                    • facebook
                                    • google
                                      Password icon
                                      Signed in as (Sign out)

                                      We’ll send you updates on this idea

                                    • Echo source/target on Resolve Missing Dependencies page

                                      If you are using Gearset to deploy between multiple orgs/repos, you may find you have launched the analyzer on multiple tabs within the browser (or across browsers). Since this operation takes some minutes, when the page 'Resolve mIssing Dependencies' appears, you get no clue as to the source/target. In today's multi-tasking life of a developer, it is easy to get lost and forget which tab was for which deployment.

                                      Basically, the principle should be to echo the source/target in the header of all pages/dialogs - especially if the operation to arrive at that page is not 'instant' wherein the user…

                                      1 vote
                                      Sign in
                                      Check!
                                      (thinking…)
                                      Reset
                                      or sign in with
                                      • facebook
                                      • google
                                        Password icon
                                        Signed in as (Sign out)

                                        We’ll send you updates on this idea

                                      • Warn when deploying objects without profile settings

                                        I build a VF page, test it, deploy it and discover much later that I forgot to add profiles other than system admin to the page. Users can't see the page and get a permissions denied error.

                                        So, the suggestion is to have a an optional analyzers that warns when deploying a new VF page to a target org where the only permission is System Admin. While this could be legit in some use cases, in most use cases, this is a self-inflicted omission.

                                        2 votes
                                        Sign in
                                        Check!
                                        (thinking…)
                                        Reset
                                        or sign in with
                                        • facebook
                                        • google
                                          Password icon
                                          Signed in as (Sign out)

                                          We’ll send you updates on this idea

                                        • Avoid spurious Analyzer message for Permissions on required fields

                                          If you deploy permissions for, say Task.Type, Gearset deployment analyzer displays: "Exclude the following from the deployment - Field permissions for fields that are probably required fields on the target"

                                          Field Task.Type (V39) is not a required field. If one ignores the suggested exclusion, permissions deploy just fine.

                                          Elimination of spurious analyzer warnings increases utility of the remaining analyzer messages that are the raison d'etre of Gearset

                                          1 vote
                                          Sign in
                                          Check!
                                          (thinking…)
                                          Reset
                                          or sign in with
                                          • facebook
                                          • google
                                            Password icon
                                            Signed in as (Sign out)

                                            We’ll send you updates on this idea

                                          ← Previous 1
                                          • Don't see your idea?

                                          Feedback and Knowledge Base