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

    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

  2. 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 or 2…

    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

  3. 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…

    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

  4. 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…

    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

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

    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

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

    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

  7. 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 add/remove field…

    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

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

    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

  9. Add an analyzer/repair option for ConnectedApps w/ ConsumerKeys

    ConnectedApps are part of the Default 64 metadata set. yet if you try to deploy a ConnectedApp that uses a ConsumerKey in the source org, you will get a deployment error either "The consumer key is already taken" if target org has that ConnectedApp already or "You cannot provide a Consumer Key" if a new ConnectedApp

    Since the deployment is going to fail, there should be a Gearset Analyzer that checks for this and removes from the deployment

    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

  10. Clarify installation of managed packages and allow opt-out

    It appears that if there are dependencies in the deployment that require a Managed Package to be installed/updated, that package is automatically installed/updated before the deployment takes place.

    This is great, but it needs more clarity and control for the user.

    It would be nice to know if Managed Packages are going to be installed as the result of a deployment, and if so, opt-in or opt-out of that process. It would be great if opting-out also displayed the related metadata with the dependency so those could be excluded as well.

    This may also avert some errors where metadata needs…

    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

  11. When migrating ReportFolders, either remove running user or let me map users between Sandboxes/environments

    When migrating ReportFolders, either remove running user or let me map users between Sandboxes/environments

    The SharedTo User doesn't exist in the target org causing my deployment to fail.

    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 3 Next →
  • Don't see your idea?

Feedback and Knowledge Base