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.
1354 results found
-
Warning On Missing Custom Metadata Field
I had a deployment fail today due to a difference between a custom metadata type's definition in the source org vs the destination. The source had two extra fields that the destination did not have. This cause the metadata record deployment to fail, because two extra values were included in the deployment which did not have corresponding fields in the destination. Because the fields were for a custom metadata package, I was unable to (easily) add the fields into the destination org.
I'd like to see a way to suppress custom metadata values. This may be solvable through the inline…
1 vote -
Warn about Email Deliverability setting
Warn users when they are about to deploy (data OR metadata) to remind them when "Email Deliverability" is turned on.
1 vote -
Allow deployment of Email header/footer changes
Examine changes to Email Footers and allow deployment of changes.
1 vote -
Ability to chose SFDX source format (force-app) compare or old style (src)
Add a checkbox to chose wheter we want a sfdx compare or an old one (in order to not let gearset chose for us)
1 vote -
Separate the Custom Settings <object> Permissions and Metadata Type permissions from the Profile or Permission set
When promoting Custom Objects and their security, we have to look at Custom Object Permissions (after loading the respective Profiles and Permission Sets in addition to the Custom Objects). We should follow a similar model for Custom Settings and Custom Metadata Types. The reason is that, if they remain part of the Profile or Permission Set, then I have to make sure that the Profile or Permission set exactly matches what I want in the target environment - I can't have any extra Custom Settings or Metadata Types that don't exist in the target environment yet or the promotion will…
1 vote -
add a wrning
when adding filters in the manage custom filters section can you a check to see if the contents look like regex, and the type selected is "object name" can you pop up a warning aong the lines of "Are you sure you don't want a regex filter?"
1 vote -
Possibility to add automatically added metadata to the comparison after a failed deployment
The dependency crawler that GearSet offers is one of its biggest strengths. A lot of manual labor can vanish at the click of the button. Best example would be the addition of all relevant Picklist fields when a Record Type is added to the Selected Items.
Sometimes deployments still fail, and in particularly big orgs the dependency crawl takes ages, each time I have to rerun the problem analysis.
A way to add the metadata that was auto-added prior to the deployment to the list of Selected Items to make future analysis faster would be greatly appreciated.
1 vote -
Allow editing Orgs created by other users
If there is a Gearset user who adds a bunch of orgs, and then quits-- and then a password change is needed for those orgs (or even something simple, such as a nickname change-- it is impossible for another Gearset user to edit the previous Org.
A workaround is possible to remove the previous Org and add a new Org, but this could lead to lost comparison history, something that many businesses (mine included) care a lot about.
Can access to edit Orgs created by other users be added?
1 vote -
Support Salesforce standard Country/State Picklist Mapping for Data Masking
Right now, using the data masking feature for data deployments, the values for country and state are real values and random. There's no guarrantee that the country and state will be valid pairings.
This causes issues for orgs that use the standard Country/State picklists from Salesforce.
The goal would be that the masking feature would pull from the Saleforce default values and make sure that the state and country are valid pairings as opposed to randomizing both separately
1 voteGearset will now only use US states and “United States” for the country, meaning that the pairings are always valid.
-
1 vote
-
1 vote
-
`Deployment history' User Interface update.
In `Deployment history' it would be great if when you choose a target and it opens in a new window. Deploying 48 packages and it is painful.
1 vote -
Allow merging functionality when two branches are compared
right now, when compare/deploying two branches, Gearset only fetches the new changes and creates a whole new separate commit to be pushed to the targeted branch. This causes the targeted branch to lose track of all previous commits from the source branch and when compared in git, it thinks that the targeted branch is still behind. It would be very useful, especially for admins, to be able to use merge compatibility if and only there is no conflict between the two branches.
1 vote -
Add a column to indicate if XML matches if order doesn't matter
See this link: https://docs.gearset.com/en/articles/2413367-why-is-xml-order-of-some-metadata-in-the-comparison-results-different
Sometimes, the XML of an item in sandbox/production can be the same, but not in the same order. This leads to false positives showing up in the list as "changed items".
I understand that sometimes order matters (eg: in picklists) but maybe there could be an additional column which shows if there are no differences if you ignore order? Maybe even a setting to turn the column on and off so it's not confusing?
1 vote -
Changed by and Changed Date not populating from DX structure in Repository
Using the DX/source structure in a repository (Github), no "item changed" date is shown for any metadata types in the comparison window.
This leads to gearset not being able to provide last changed date or who last changed anything in a Source DX repository. It's left with "unknown" and makes our comparisons and selections more difficult when users rely on that information.
1 vote -
Ability to override custom metadata field settings per org
Our code repository currently contains the custom metadata settings from our development environment. When we deploy to production, we either ignore custom metadata in Gearset and manually add any new custom metadata items to production or we manually select the new custom metadata items in Gearset and then manually update the fields in production from the development settings to the production settings.
It would be great if there was something like the Octopus Deployment tool has where you can define configuration settings for each environment. Gearset would automatically update the field value based on the stored setting for the specific…
1 vote -
Improve the UI around deployment objects dependent on objects not in the comparison
Deployment of certain types of objects requires that other objects on which they are dependent be included in the deployment. If the needed objects have not been included in the selected items and they are not part of the comparison, Gearset will display the following message:
Problem: Some itmes reference componnents that were not downloaded from either the source or the target.
Solution: Removing the elements that reference missing components from the affected items will make the deployment more likely to succeed.
Below this is displayed a table with a column of checkboxes at the left and three additional columns:…
1 vote -
Support VS Code extension: ForceCode
Can you please support VS Code extension (ForceCode) source format so that we can use the extension to commit and include in CI jobs.
1 vote -
Ignore sfdx-project.json file in order to compare code using Metadata API structure
I need use the sfdx-project.json file in order to integrate with VS
code, but using Metadata API structure.
Apparently, Gearset is looking for this file to define if is a metadata API or SFDX structure,So I need a ignore looking for this file, in order to compare as metadata API structure.
Thank you.
1 vote -
Display "No Difference" metadata sources on Deployment Summary page
On the "Deployment Summary Page" it would be great to add a column to the list of metadata components added which shows for the "No Difference" items showing the source piece(s) of metadata which is causing this "No Difference" to be included.
This would dramatically help in the narrowing down of why a piece of metadata is included - especially if that piece of "No Difference" is a managed package and cannot be altered. In a large deployment, trying to identify a root cause for why a component was added is quite difficult. Simply giving a way to track back…
1 vote
- Don't see your idea?