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.
1311 results found
-
Allow deployment of 'Check For Matching Records' in Flows.
As part of the new Salesforce Summer ’24 release, Salesforce have added the ability to check for matching records when using a ‘Create Records’ element. We’ve used this useful feature in various locations within our new flows to identify existing contacts for example.
When deploying the flows using this feature between developer environments via Pipelines or Compare & Deploy in Gearset, we’ve noticed that this new setting within the element doesn’t get deployed and is switched off in the destination org.
In the meantime, we can manually turn on this feature in the destination org.
1 vote -
Add the "cloned from" friendly name somewhere on the comparison page.
This suggestion is specific to comparisons that are initiated by cloning a package (that already has been named). Gearset / salesforce takes a bit of time to finish its comparison/validation, so often times I'll open up to 5+ tabs one for each of my gearset deployments. As the comparisons complete, I'll move between the tabs to progress through the steps, but as you can imagine it gets confusing which compare is cloned from which deployment.
Possible ways to display on UI:
When cloning a single package -
e.g.
Apps-87431When multiple packages are combined -
e.g.
Apps-87431
Apps-87431-Step2
Apps-87431-AddFieldUsually,…
2 votes -
Save sort order in Saved comparison pairs
It would be nice that the chosen sort order of the saved comparison pairs could be saved.
If I choose to sort the saved comparison pairs on Friendly name and i open a new tab of gearset, the saved comparison pairs in the new tab are sorted on last used. It would be nice that in the new tab, the saved comparison pairs are sorted based on the same column as the previous tab.1 vote -
Add an option to ignore API version differences during comparisons
When comparing Apex, and other files with API versions the difference engine will mark any files with higher API version as "changed", even if the API version is the only change. This can be undesirable when there have been bulk updates to the API version that have not been made in the development environments. It would be great if the comparison engine could make it clearer when the only difference between two files is an API version (especially when the target is on a higher API version)
2 votes -
Split Lightning Page Metadata Type
Think the Lightning Page metadata type needs to be split into 2 categories. Reason being it is the one metadata type that causes comparisons to run for extremely long times or even crash/time out. This happens because it trying to compare all of the lightning email templates users make. It would be better if lightning email templates were their own metadata type and the lightning page type was actually just lightning pages created for objects.
2 votes -
Allow open PRs to queue up.
Allow open PRs to promote via selection and to queue up against the target keeping blocking behaviour to just merges and the deploy activity
1 vote -
4 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 -
Picklist Comparison should show if value is active/inactive
When comparing a picklist in which we have deactivated values, the simplified comparison visualization shows the deactivated values as being "added" (in green, on the source side).
The XML reveals <isactive>false</isactive> is being added, but the simplified view seems to suggest new values are added instead
1 vote -
New, one-click "Promote" button is very risky
In Deployment Pipelines when a PR for a CI Job is selected, a new, one-click "Promote" button exists, if the PR passes merge-conflict and validation checks. This new button is very risky in that it begins the promotion process, without recourse, when clicked.
Perhaps that's the designers intent but for myself at least, the button is too easy to accidentally click out of inattention, distraction or mouse clumsiness and is especially risky in that I cannot recall the action.
Personally I like the process of clicking the PR checkbox and clicking "Promote", which prevents unintended deployments.
As an alternative to…
1 vote -
Display auto-merged files during Conflict Resolution
The Conflict Resolution only displays files that require manual resolution. Sometimes I want to see the files that were automatically merged without human intervention.
The only way to see this is to submit a resolution as is, then read through the file changes again to look for files that were auto merged/resolved from target instead of source.
2 votes -
Allow users to select a default comparison view between 'Permissions View' and 'XML view'.
During comparisons, I constantly have to select the XML view when I click through rows of metadata as it keeps defaulting back to the Permissions View, I don't particularly find the permissions view that useful and I'm also used to XML views, would appreciate if you could give users a choice in a 'default' view to improve experience.
2 votes -
Automatic analysis for metadata
Adopt automatic validation for API names of custom objects, custom fields, custom settings, and custom metadata types. Additionally, ensure that the "Description" field is populated to enforce documentation by administrators and developers on Salesforce metadata, including custom fields, custom objects, automation (Approval Processes, Flows, Entitlement Processes), and other applicable metadata types.
2 votes -
audit report missing PR message
The audit reports don't include much context of the deployment, which means they are pretty useless to us and do not serve our auditors' needs. Specifically, they do not include the PR message for deployments through our pipeline, which means we can't link each deployment to the specific ticket responsible for that deployment. The PR message is where we put our ticket. This information is needed for our SOX audit process. Additionally, we can not see a link back to the deployment, which would allow us to quickly reference the specific metadata files/components that were deployed.
1 vote -
Pre-fill Pull Request Description with comments from last commits
In order to save time, when a Pull Request is created from the Pipeline, the Description field could be pre-filled with the comments from the last commits in the feature branch, instead of forcing the User to type something.
1 vote -
Use location of metadata in source branch or local folder when adding to target branch
When adding a file from a branch or local folder (source) to another branch (target) not having the file, use its location in the source as the location in the target.
Currently all new files are placed in the default folder [1].
Let's assume a new file, "HelloWorld.cls", in the source is located in .../force-app/main/default/classes/special/ and that class doesn't exist in the target. When the deployment is complete the file should exist in the target's .../force-app/main/default/classes/special/ folder, matching its location in the source. Currently it would be placed in .../force-app/main/default/classes/.
[1] https://docs.gearset.com/en/articles/2835001-structuring-your-source-control-repository
1 vote -
Save sort order of grids
It would be nice to be able to sort by column names and save that sort order for the next time the page loads or save a default sort order. We sort often by jobname and would like to not have to resort everytime we need to touch a ci job to sort the column.
1 vote -
allow automatic publishing of an experience site after deployment
Just like you can automatically activate Flows in Gearset upon deployment; it would be nice to automatically publish deployments of Experience Bundles. This is especailly true for deploying Experience Bundles to staging/qa orgs but applies also to PROD.
There's an API to do this: /connect/communities/communityId/publish documented https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_communities_publish.htm
3 votes -
In a data deploy, allow filtering data by previously deployed parent objects.
For example, instead of "Only deploy Opportunity records that are children of the Account.Opportunities records that are being deployed" which filters opportunities by the accounts in the same deploy. You would have two deploys. The first would deploy accounts. The second would filter opportunities by those accounts already in the target org.
This would allow you to modularize deploys. You might want to mix and match subsets of data for specific projects. It would allow working around some of the shortcomings of the account hierarchy gearset magic. If there were transient errors (like exclusive locks) you could repeat a smaller…
3 votes -
Add support for CMS Collections
Please add support for CMS Collections in the comparison filters as well as the deployments and CI jobs.
We're working with CMS Collections in our current developments of a customer community and we'd like to deploy this metadata as well.1 vote
- Don't see your idea?