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

    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

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

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

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

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

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

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

  8. Provide output from Gearset during the validation in terms of what tests were being run

    I had unit testing jobs running ALL tests in source (full sandbox) and target (production) org - resulting in 80% and 79% test coverage. However, when I started to deploy my changes - the validation failed because test coverage was only 74%. Finally, after a few days, I figured it out.

    I was just simply clicking "Validate" (i.e., did not choose specific tests). In the past - that ran "all tests". But something seems to have changed. When I picked "choose tests", about half the tests in my org were "automatically selected". I manually selected all other tests - effectively…

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  9. Add Analyzer for "Cannot delete the only layout"

    This is a common issue with deploys from VCS to orgs and especially so for standard objects when SFDC introduces new versions and hence new objects

    Example: In V53, SFDC introduced Standard Object "Customer"

    If your VCS doesn't have a CustomObject for Customer and a Layout for Customer, the CI job will attempt to delete the Layout and get an error - you can't delete the only layout"

    The Analyzer should detect this with recommendation to not delete; then CI jobs can honor this and not fail

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  10. Warn on Master/Detail deployment even without comparing Custom Fields

    If you compare Custom Fields and try to deploy something in an Object that is in a Master/Detail relationship without including the Lookup field, Gearset will warn you that the deployment will fail.

    However, if you don't include "Custom Fields" in the comparison, (for example just comparing Validations) and try to push it, you will hit an error:

    "Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field"

    Gearset could easily warn the user on this when trying to push a Validation Rule on a MasterDetail object, even if Custom Field was not added to the comparison.

    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. Add Repo Cleaner support to SearchSettings

    When you delete a custom object, the Repo Cleaner should remove the references to that custom object in the Settings metadata type - specifically SearchSettings | <searchSettingsByObject>

    Otherwise, it becomes impossible to deploy Search Settings via CI jobs

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  12. Improve error message when XML is not properly escaped

    When I choose to compare metadata with my source as my VCS, there was an "&" char in the recordtype XML definition file.

        <values>
            <fullName>Food & Beverage</fullName>
            <default>false</default>
        </values>
    

    This threw an error and there was no support and no explanation at that time.

    I suggest you to improve this error message.
    Message I got:

    Could not parse the XML for 'force-app/main/default/objects/Lead/businessProcesses/Buyer.recordType-meta.xml'. Error occurred at line 71. Further details: An error occurred while parsing EntityName. Line 71, position 29.

    File, line and position it's ok. maybe a link to Gearset docs with walkthrough with this probable cause when a parsing…

    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

  13. Display API name and friendly name of permissions within Analyzer messages

    when Gearset Analyzer tells you that you should consider removing a permission from the deployment, it displays the API name of the permission but often this doesn't tell you what item in the Setup UX you need to check on

    example:

    ContentHubUser is actually the permission for Files Connect Cloud My suggestion is that Gearset take advantage of this resource http://www.fishofprey.com/2020/10/mappings-between-salesforce-permission.html and display both the API name and the UX name in parens - such as :
    ContentHubUser (Files Connect Cloud)

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  14. 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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  15. Don't Delete Managed Package's object permissions from Permission Sets in CI jobs

    In a CI job, using source control as the source and including deleted items, you can run into an issue where objects from managed packages show as "deleted" in terms of custom object permissions from permission sets that have access to them. This can occur for permission sets designed to give access to managed package features or if you have a permission set with "View all data" or a system permission that gives them access to all objects in some capacity (read, write).

    Ideally, we wouldn't have to include managed package object permissions into Source Control (likewise, Gearset suggests only…

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  16. Workflow failed to deploy without error, due to standard object dependency

    In a CI job : Validation shown as success & Deployment shown as success. But actually no workflow deployed due to it being removed in the Problem Analyser.

    The Problem Analyser triggered due to the (standard) object, that the workflow depends on, not being in the comparison results.

    In a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap - problem analysers should never fire on object dependency.

    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

  17. Workflow failed to deploy without error, due to standard object dependency

    CI job : Validation shown as success & Deployment shown as success.. but actually no WF deployed. Saying Opportunity object doesn't exist in target just because it was not selected in the components. in a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap.

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  18. Excluding Record Type Problem Analyzer Should Behave the Same Across Metadata (Layout Permissions, Custom Object Permissions)

    In the situation where a repository is the source and an org is the target, there may be a situation where a record type doesn't exist in the repository but references in the layout permissions and custom object permissions do still exist.

    Currently, the problem analyzer will catch the custom object permissions and ask you to remove the references to the record type that doesn't exist in the target.

    However, it doesn't catch the layout permissions and the deployment could fail with an invalid reference.

    In the absence of the record type in the repository, the "Problem Analyzer for excluding…

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  19. Warning On Missing Custom Metadata Field

    I had a deployment fail today due to a difference between a custom metadata type's definition in the source org vs the destination. The source had two extra fields that the destination did not have. This cause the metadata record deployment to fail, because two extra values were included in the deployment which did not have corresponding fields in the destination. Because the fields were for a custom metadata package, I was unable to (easily) add the fields into the destination org.

    I'd like to see a way to suppress custom metadata values. This may be solvable through the inline…

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  20. Possibility to add automatically added metadata to the comparison after a failed deployment

    The dependency crawler that GearSet offers is one of its biggest strengths. A lot of manual labor can vanish at the click of the button. Best example would be the addition of all relevant Picklist fields when a Record Type is added to the Selected Items.

    Sometimes deployments still fail, and in particularly big orgs the dependency crawl takes ages, each time I have to rerun the problem analysis.

    A way to add the metadata that was auto-added prior to the deployment to the list of Selected Items to make future analysis faster would be greatly appreciated.

    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

    0 comments  ·  Problem analysis and deployment failures  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base