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.
1235 results found
-
Help users Deploy Sales Cadences between orgs
Sales Engagement for Salesforce allows users to build Sales Cadences. These seem to be record based, so being able to move these between orgs would be great.
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 -
Add Manage Custom Filters option when creating a CI job
When I use options Automation -> Continuous Integration -> Dev Sandbox -> Compare and commit for deployment, there is no option to create a custom filter.
Custom filters can only be created by using Metadata deployments -> Compare and deploy option.
Since the following tutorial https://docs.gearset.com/en/articles/6166062-promoting-your-first-features recommends to use Automation -> Continuous Integration for deployment, it would be nice if this way of deployment also had an option to create custom filter.1 vote -
Allow users to select custom fields even if the object does not exist in the target
Would be great if GS allowed to select custom fields when doing a comparison even if the object does not exist in the target. If I am pushing changes to a repository I might want to only include the fields I created/modified and not the whole object.
15 votes -
Share org connections or CI jobs with sub-teams
As an SI, we use Gearset for release management with multiple clients. Each client has multiple environments and CI jobs, but not everyone on my team works with every client. Currently, I can either share an org connection or CI job with all members of my team (providing access to people who should not have it) or I can share it individually with each person working with the client (which can sometimes be up to 10 people). It would be useful to define a group that holds the people who work on the client account and then share org connections…
1 vote -
Ability to use include/exclude patterns for Apex tests
Now we can only have patterns to match test classes to include.
Would love to have ability to use include/exclude patterns (like for comparisons).
We have many tests which we don't want to execute within CI jobs. These could be from (stable) 3rd party libraries like FFLib.2 votes -
Add the package Name to the page, when the package is Opened
Currently when you Open a package like a draft deployment, the Name of the package does not appear. There is a message in top L-H 'Comparison finished' which is not very useful. Perhaps the package Name could go here. It will reduce confusion as you will be able to tell which package you have open. Thanks.
2 votes -
Trigger Gitlab Pipeline Faster
When opening a MR in Gitlab, the Gearset pipeline queues the Validation very quickly. However, in Gitlab, there is no pending Pipeline until Salesforce starts the validation. Sometimes this can be a lengthy period of time with no visibility inside of Gitlab.
Would be nice to trigger that immediately so approvers can see that it is queued, not just no pipeline job has been executed yet.
3 votes -
Disable Pipeline Back-propagation for Static Environments
We would like to have the option to disable the back-propagation in the pipelines for static environments or have more options to control how the back-propagation should behave, like not running the PR validations for these types of Pull Requests.
When new changes reach the master branch, those changes should be pushed to the branch linked to a Salesforce environment. As it is today, the changes are back-propagated through new Pull Requests and because of the pipeline default config, the unit tests need to run which can block the sandboxes for some time depending on the complexity of the release…
3 votes -
Ability to report on runtime in Gearset Reporting API and what metadata filters were used
As part of showing the amount of time saved by using Gearset (and DevOps best practices), as well as the overall current utilization of Gearset across multiple teams and Gearset instances, being able to report on the Comparison, Validation, and Deployment runtime would be extremely beneficial. Also reporting on which metadata filter was used, if named and saved/accessible, in a comparison, validation, and deployment.
This data could also be used to identify inefficiencies in the standard metadata filters used across our Gearset instances, and potentially identify clients not deploying smaller and iteratively in order to prove with data how that…
5 votes -
CI job merger conflicts
When resolving CI job merge conflicts, a user has two windows to accept changes from one side of the window. Can we have an option to accept specific components changes from one side and certain changes from the other side.
4 votes -
Pipeline Sync Environment & Dev Environment
Currently we only have the ability to sync static pipeline environments. This is well and good but unfortunately syncing the Project branch can be time consuming and confusing Its not as simple as syncing the static environment.
I suggest when I sync the static environment , the sync action automatically opens a back propagation PR to the Dev environment its connected to. Also this sync action should close any pending open PRs against that dev environment that overlap with the sync PR.
2 votes -
Add wildcard Test selection
When selecting tests to be run for validation or CI validation jobs, we should be able to select "Test classes" and provide more generic search names such as "Test.cls" or "classes/". This would allow dynamic updates to the selected tests based on available test in the deployment package.
1 vote -
Show Metadata API version used to retrieve metadata for comparison on comparison result page
It would save time and give confidence if the specific Metadata API version number used to retrieve the metadata was displayed on the comparison results page.
2 votes -
Precision Deployments (available for Layouts) for all the meta data
Precision Deployments for Layout is a great improvement, it would be great to have the same feature for other meta data, particularely for : Fields picklists, global value sets, List Views, Reports, Profiles, Permission Sets and why not Lightning Pages, now that the Dynamic Form is available for Acc, Contacts & Opp
19 votesAll - please let us known in the comments which metadata types you would like us to support next with precision deployments. Thanks
-
Pull Request Branch Filter/restriction
Currently creating a pull request from the "Create pull request Screen" provides the user with a list of all the branches.
The default of this seems to be based on the last location you had selected when you created your branch (This usually ends up being main). As we have a pipeline this is the last place you want anyone being able to create a PR into!
It would be great if we could whitelist/blacklist a bunch of Branch names on this dropdown to stop users accidentally selecting main when creating a PR (for most users this would be one…
2 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 -
Expand the options for "Run job" times on the continuous integration job setup.
Currently the "Run job" option has times for 1, 2, 4 and 24 hours. With international teams working on projects, it would be nice to allow for something like every 8 hours. That could either be a new set option in the list, or allow for a "custom" option. If the pipelines can handle between 1 and 24 hours, let us selection "custom" and input the hours for the job interval to run.
6 votes -
exclude specific JSON keys when comparing Vlocity/Omnistudio metadata
We are seeing Omniscripts showing as different on certain JSON keys. These keys always change and should be excluded from your comparison.
The impact of this is Omniscript deployments require the LWCs to be compiled and if we deploy Omniscripts unintentionally, their LWCs are not recompiled and functionality breaks for the users.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
- Don't see your idea?