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.
252 results found
-
Cache deployment inspection results
It would be great if deployment inspection results were cached, such that the results for an identical set of metadata are available without spending the time to recheck everything.
Use case: A comparison is performed and all changes selected. Deployment inspection is performed and recommendations are made for items to add/exclude. I select a subset of recommendations, and move forward with validation. The validation fails. The same comparison is reopened and again all metadata is selected (with the intention of selecting more of the add/export recommendations resulting from the inspection). At this point, the inspection is rerun, even though the…
1 vote -
Add an option to use a custom "Gearset format" for the source control output
The XML that comes from Salesforce is weirdly bundled together. When changes are made it's really hard to reconcile two branches in source control when merging.
When comparing, Gearset nicely decomposes changes into smaller chunks. So instead of putting that back into the usual XML, an option to store that "internal format" and even just stick it as JSON or similar.
After all - it'll be Gearset reading it back in to compare to an org next time, and smaller changes will be easier to merge as they won't conflict inside horrendously large XML files
1 vote -
Provide link from standard field to Standard Value Set
Some of the standard picklist fields in Salesforce have their values defined in Standard Value Sets. This means when you add a new value in the Salesforce UI, for example in the Type field of the Case object, that you are actually editing the CaseType Standard Value Set and not the Case Custom Object.
Gearset detects all these differences, but it isn't obvious why Case.Type appears as unchanged in a Gearset comparison. It would be better if Gearset showed some help text in the Case.Type object definition that pointed me to some help docs or linked me to the exact…
2 votes -
In comparison mode, remember whether I want to see the XML view or a friendlier view of the object I'm looking at.
I noticed that the non-XML option label changes depending on what type of object I'm looking at. Regardless, if I select the non-XML option in comparison mode, I'd like the site to remember that option during my session so I don't have to keep re-clicking the non-XML option for each line item.
1 vote -
Filter out Custom Field differences based on Field Tracking History
If the only difference in the field is that History Tracking is turned on, it would be nice to filter these results out.
Running checks on our app with multiple customers, who all set history tracking differently, can create a lot of noise to filter through to find actual differences.
3 votes -
Add a validation/warning for when users try to filter only permission set for comparing and deploying
we believe that if we are given the option to filter only permission sets for the comparison, there should be some type of validation ensuring that you are also including dependencies such as custom objects, apex classes etc so that we don't make the assumption that filtering permission sets only in the comparison will include all dependencies
1 vote -
Filter standard vs custom objects
We sell a managed package and will never include standard objects in a comparison, and absolutely not in source control. When I'm running a compare against source control to check for changes, it will show all of the standard objects as "custom objects" which is not correct. I should have a way to filter out standard objects from the comparison.
1 vote -
Warn if a selected metadata type is not supported by selected API version
In the custom filters dialog, if you select a metadata type that is not supported by the API version, the compare and deploy currently just silently ignores that item, giving the impression that the compare has failed. e.g. selecting "Duplicate rule" with metadata version prior to 38.0.
It would be good for Gearset to provide a warning if a selected metadata type is not supported by the selected API version.
2 votes -
Enhanced Comparison filter - filter by difference count
My use-case would somewhat be handled by separating code and xml differences, but I would like to be able to filter on difference count (or at least, easily see / sort by diff count).
For example: We are updating the API version on all of our classes and triggers (about 279 files this go around) and I want to make sure that the API update is the only diff when doing a deployment. Or to be worded differently: only deploy files where the only difference is the API version.
1 vote -
Suggestion - make comparison highlight colors configurable
The background highlight colors for differences are much too light to be able to be seen clearly when viewing in APEX mode. Colors are much brighter in XML mode. Request - allowing these colors to be configurable. Thanks for the consideration.
1 vote -
A count of differences could be grouped by type
If the count of differences could be grouped by type/color that would be helpful.
Ex: 20 differences: 5 red, 7 green, 8 yellow. It gives a better sense of how drastic the differences between Source and Target are at first glance.3 votes -
Dependency Engine enhancement for Sharing Rules
Dependencies with sharing rules. Roles/Groups/Fields referenced in sharing rules may be helpful to add as "dependent" on as if they are not in the destination org you cannot deploy.
2 votes
- Don't see your idea?