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
-
Stop Off-setting Partial Selections when a Package is 'Fetched' for the Latest
Hi,
Our team creates individual draft deployment packages and then we consolidate it into one package and fetch for the latest before validating. In some of our individual draft deployment packages we are selecting partial changes to a page layout or a lightning record page but it is off-setting this partial change and we are given the prompt: 'Precision selections have been reset for these items'. Is there a way we can fetch for the latest without off-setting these partial changes?
Thanks!
2 votes -
Problem Analyzer while building the deployment
Surface problems with building the deployment to allow users the correct in the deployment.
1 vote -
Check for maximum flow versions reached as part of the pre deployment error check
The problem analysis does not detect that the deployment will fail due to max number of flow versions
2 votes -
Please adjust problem analyser feature to show record type changes when a picklist field value is added.
Currently Problem analyser does not show any warnings or issues when record types are not selected for a picklist field changes( value addition). With this during deployment there is fair amount of chance that some one could easily miss record type changes. Please adjust problem analyser to account this situation and show record type changes as warnings would be beneficial.
2 votes -
Problem Analyzer should remove picklist values from record types when picklist values are removed from the picklist or value set.
When removing or deactivating a picklist value, Problem Analyzer should remove these values from any record types that reference them. While the initial deployment of the picklist may succeed, subsequent deployments of the referencing record types will fail if they still reference a deactivated picklist value.
1 vote -
add Dashboard owner to Problem Analysis to use user deploying instead in xml ref
Spring '24 Salesforce added ability to change Owner on a Dashboard https://help.salesforce.com/s/articleView?id=release-notes.rn_rd_dashboards_change_owner.htm&release=248&type=5
"Previously, you had to clone or re-create the dashboard to provide access to a new owner."
This can now cause deployment errors when the Owner is changing between environments if the Uesr does not exist, similar to runningUser user references. Problem Analysis accounts for the latter, but not the Owner. Could we add the Owner scenario to this analysis rule?
1 vote -
apex classes dependencies
When deploying an apex class, check for dependencies. Currently it attempts to deploy even if there are missing fields and only reports missing fields one at a time. Very tedious to address.
1 vote -
Bulk resolving merge conflicts across multiple PRs (set resolution as Feature or Environment)
It would be great if there was the capability to bulk-apply Feature or Environment when resolving merge conflicts across multiple PRs. 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.
3 votes -
Add to Problem Analysis option to auto remove DelegatedAccount tab settings
Add to Problem Analysis option to auto remove DelegatedAccount tab settings since it's an invalid tab and can cause validation/deployment errors. This saves a step of having to change Custom Object filter to Named Items and manually exclude DelegatedAccount when moving new profiles.
1 vote -
Highlight "Failed Validation" Components
If the metadata Deployment Validation step fails, and the user clicks the "Back to Comparison" button, the components that caused the failure should be highlighted on the screen for manual review.
Currently, when a deployment fails on the validation step, my process is:
- Wait until the Validation step is done
- Sort by the Status to show Failures on top
- Take a screenshot of the list of errors (hopefully less than a full screen of errors)
- Click the "Back to Comparison" button
- Use the screenshot like a checklist to work through the errors
- Run Validation…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 -
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 -
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…
4 votes -
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.
3 votes -
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 -
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.4 votes -
Validation job when PRs are raised
Requirement :
Provide option to create a CI Validation Job only with "Validate pull requests targeting the source branch" and keep "Run Job" dropdown as optional .As Of Now :
When we raise a PR, it initiates feature branch validation ( cos, we enabled "Validate pull requests targeting the source branch" ), and after that when we merge feature-branch to target branch, it re-initiates another validation job.
For us, it's like similar validation is running twice on different events from which we can't opt out.Pros :
We can handle when to validate a feature branch, instead of bundling…
1 vote
- Don't see your idea?