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.
81 results found
-
Bulk selection of Use Feature or Use Environment resolving merge conflicts
It would be great if there was the capability to bulk-apply Feature or Environment when resolving merge conflicts. I have a few dozens that all need to be set to the same option, and it would be useful to handle this quickly rather than click on each one individually.
1 vote -
Enable data fixes when migrating Vlocity datapacks
When the data in the source and target environments are aligned, deploying Vlocity datapacks with Gearset can be quite straightforward.
However at times when they are not, deployments can fail catastrophically with the documented solution requiring the use of tools provided by Vlocity / Salesforce Industries in their Vlocity Build Tool : https://github.com/vlocityinc/vlocity_build. The alternative is to try manually resolving the issues, which can be an uphill struggle when you consider complexities around products, such as their hierarchy, availability and pricing.
For Gearset to truly be a one-stop tool for Salesforce Industries deployments, please enable data fix functionalities in…
1 vote -
Flow equivalent of Static Code Analysis-esque rules
Code Analysis rules run against Apex in Gearset. As Salesforce development continues to rely on Flows as the main tool for declarative automation, it's becoming challenging to catch known inefficiencies, known issues, and discouraged usages. It would really set Gearset a part as a deployment tool to utilize issue detection or run "rules" against Flow metadata to call out potential issues or flows not following best practices to even prevent a deployment or commit from occurring.
Examples: SOQL or DML in a loop, the number of elements for flows (prior to api v57) or general overall complexity, lack of Descriptions…
5 votes -
False error - 'Field permission cannot be set for Required Fields'
Deploying few field permissions through CI, there is an error 'Field permission cannot be set for Required Fields' in the Problem Analyzer, but actually the fields are not marked as Required in the target. Lead.Pronoun, Lead.GenderIdentity fields.
1 vote -
Add api version check validation
We have experienced quite a few errors when a metadata component is developed in a sandbox that has been updated to the preview api version but production hasn't been updated to that version yet. Our entire pipeline and PR validation process works perfectly until the very last step when deploying to production. It's very difficult to deal with at that point.
2 votes -
1 vote
-
allow configuration of problem analysers for different target locations
If we could turn of problem analysers for specific locations (e.g. Git repos) this would allow us to remove irrelevant problem solutions from our git commits, but keep them for deployments
1 vote -
package missing -meta.xml endings
When I download a package from a CI Job, it doesn't include the require "-meta.xml" ending for my metadata types. I wrote the following script to add them back one folder at a time. It would make more sense if Gearset just gave me the correct filenames when I download the package though.
…# Gearset gives us a downloadable package to trouble shoot, # but it doesn't have the -meta.xml text appended to it. # Find all files with this ending and append -meta.xml to it. find ./ -type f -name '*.flow' | xargs -I '{}' mv '{}' '{}'-meta.xml find1 vote -
Set Problem Analyzer to default with all rules disabled
Problem Analyzer rules are automatically enforced for CI Deployments which are misleading to end user as the default has ALL rules set to enabled. My recommendations is to have the default template have ALL rules set to disabled OR have clear communication in the CI Deployment feature to notify users that Problem Analyzer rules are enabled and may cause expected deployment behaviour/errors.
1 vote -
2 votes
-
When Deploying A Page Layout, Consider Quick Actions to be Dependencies When Checking for Package Issues
Problem analysis doesn't catch if a page layout has a Quick Action that isn't present in the destination. This causes the package to error on send.
2 votes -
When Problem Analyzer adds Fields, Add Profile Permissions Too
Currently the problem analyzer will identify missing fields. However, it doesn't prompt or allow you to add the permissions for the fields. So, you either have to go back, manually add all fields as Selected, or push the package and then go back manually and add permissions for all fields. It should prompt to add both the fields and the permissions.
3 votes -
Analyzer: Duplicate child relationship name detection
Use case -
target org has child object O lookup field F1 with childRelationship = Foo
source org has child object O lookup field F2 with childRelationship = FooIf you deploy, SFDC tells you that there is already a Child Relationship Foo on O
Analyzer could detect this and warn developer before deployment
3 votes -
Analyzer enhancement - detect missing ContentAsset in CustomApplication
Given this XML in CustomApplication
<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
<brand>
<headerColor>#0070D2</headerColor>
<logo>MyLogo</logo>
<logoVersion>1</logoVersion>
<shouldOverrideOrgTheme>false</shouldOverrideOrgTheme>
</brand>If user forgets to select Content Asset MyLogo, Analyzer should detect.
3 votes -
Option to download problem analyzer template
Option to download the problem analyzer template so users have an option to add it to the custom github actions scripts to run CI validations for their own delta comparisons.
1 vote -
Bring back the Suggested Fixes in Problem Analyzer to suggest permissions for fields when moving a new field.
Previously if you selected to migrate a field, Problem Analyzer would suggest the permissions. Now it only shows up on Warnings tab. This forces you to go back to the Comparison and individually find the permissions for each field. It should include these as Suggested Fixes. Additionally, if a field is listed as a Suggested Fix, the permissions for that field should be included as Suggested Fixes as well.
3 votes -
Analyzer detection of experienceBundle routes versus views files
The Analyzer does not detect the following situation:
When the /routes/xxx.json file contains an activeViewId that is not the id in the /views/xxx.json file
This can happen (mostly user error) when one doesn’t tick both /routes/xxx.json and /views/xxx.json file in the deployment package
Example:
/routes/ReportBuilder.json
{"activeViewId" "100",
...
"routeType" : "createReport"
}/views/ReportBuilder.json
{"appPageId" : "xxx",
"id" : "99"
"viewType" : "createreport",
...
}
the activeViewId of 100 in the /routes doesn’t agree with the id of 99 in the /views
That is, the Analyzer should check that the putative deployment has properly matching references activeViewId => Id1 vote -
Don't include Wave dataflow deletes in package when Recipe is included
When deploying deletes of Wave recipes, if you include the Dataflow at the same time, Salesforce will fail validation with a DataFlow not found error. GearSet should be smart enough to build the package without the Dataflow if the corresponding Recipe is marked for delete.
1 vote -
edit problem analyser template
There should be an ability to edit the existing Problem Analyser Template. Else, one has to create the whole template again, re-do the changes on the template and then re-assign on all the existing Jobs which should use that template.
It is definitely going to save a lot of time and be beneficial overall.2 votes -
Analyzer should detect when on Report deployment if target org doesn't have Translation Workbench enabled
Source org has Translation Workbench enabled, default language is en_US; no other languages enabled
Source org develops a Report, the metadata for the report includes this line under <filter> :
<language>en_US</language>
When you deploy to a target org that doesn’t have Translation Workbench enabled, there’s no Analyzer warning and the deploy fails with
Report filterLanguage: Invalid value specified: 1.
It would be nice if the Analyzer would tell you this in a warning and suggest to remove the filter’s <language>. This would give user the option to either:
a) realize that Translation Workbench should be enabled n the target org…
1 vote
- Don't see your idea?