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.
1234 results found
-
Allow for selecting which repositories to display for github in org settings.
It would be helpful to be able to select repositories to display in the selection under Manage Orgs. Some of our repos in Github aren't related to Salesforce deployments, and filtering those out so they don't even show in the list would be really helpful in getting to selections faster.
10 votes -
Indicate whether a Validated Package is enabled for Quick Deploy
T0 - You Validate a package to PROD (run all tests)
T1 - You or someone else does a deployment of something else, no matter how minor, to PROD.
T2 - You click Deploy of the Validated Package from T0, all the apex tests are rerun. This is by design per SFDC yet Gearset doesn't tell you in advance that Quick Deploy is not available. Something you think will take a couple of minutes now takes 30 minutes or more. You think you screwed up or Gearset is broken
Suggestion: On Validated Packages page and on the page of a…
3 votes -
Show # differences found in comparison display
It would be a nice feature to see the number of differences for each item from the perspective of the source org vs target org.
3 votes -
When a Picklist Populates, Don't Default to the 1st Value, Default to Blank
When I choose my destination, the system defaults the picklist to the first item on the list. Instead it should populate the list but don't pick a value.
For example, when I choose destination = BitBucket, it then takes a moment to load available branches. It takes a little bit so I go on and start to configure the metadata types. Meanwhile, Gearset populates the list and sets the value to the 1st branch on the list, in my case, feature/helpdesk. It should leave the value blank and make me pick.
This has resulted in me running long-running comparisons, and…
3 votes -
Reuse Deployment Package (clone) should use sticky "Source Repository"
Use case:
1. Compare and deploy from repo-R/master to org A
2. Clone deployment from repo-R/master to org BUnfortunately, when the clone deployment displays the dialog "Reuse Deployment Package"...
a) When you select GitHub, the dialog doesn't default the repository to Repo-R but instead displays a picklist of all possible repos the running user has access to (in our case that is 100+)
b) Better would be to remember in cookie the repo the developer last used and default to that choice so scrolling through 100 items is not necessary.2 votes -
Allow comparisons of a single commit from a VCS
Currently, you can select a VCS repo and branch to use for comparison. It'd be great if you could select a specific commit from that branch, so that you're only looking at an atomic set of changes. This would allow for fine-grained comparison and deployment of changes.
10 votes -
Simple visualization showing Process Builder differences
Assuming the high-vote count Idea for matching on latest version Process Builder flow between source and target (and not by version #) is implemented; make the visual comparison between source/target PB not solely XML.
Process Builder in XML can't be deciphered by a human mind. Hence, a simple indented text-based visualization could be done to make it more readable
- Decision 1.1 Entry criteria 1.2 Immediate actions 1.2.1 action 1 details (XML here OK) 1.2.2 action 2 " " 1.3 Scheduled actions 1.3.1 scheduled action 1 (XML here OK) ...
- Next decision ...
There's an implicit tree layout in the PB…
3 votes -
Display "Metadata comparison (custom) filter" used on "Comparison in progress" -screen
Hi! I just started to evaluate Gearset. Looking good. When I was staring at "Comparison in progress"-screen this came to my mind:
Sometimes it takes a bit longer than expected and I start to think: "OMG - What custom filter I used? - Probably I'm comparing everything - That's why it takes so long - Maybe I should cancel this job?".
It would be more reassuring if the Metadata comparison (custom) filter being used was also shown on that "Comparison in progress" screen.
4 votes -
Show filtered counts on the results grid tab titles
When comparing two orgs. We need to show the eaxact number in the Tabs(Changed Items, New Items) when filtered.
2 votes -
Be able to switch the direction of a comparison/deployment
Sometimes we need to reconcile changes on an object between two orgs, where some of the changes have been made in Org1 and some in Org2. Having set up metadata filters, compared and deployed required changes from Org1 to Org2, it would be nice to be able click a button to switch direction to then deploy required changes from Org2 back to Org1, without having to go through the whole process of setting up a new comparison.
5 votes -
Automated User Test Suite Integration
Such as Selenium and/or Cypress.io
7 votes -
CI job status "deploying" - add dateTime
UX suggestion:
On the CI jobs page...Currently - you see last run dateTime followed by "deploying...." if a job is currently in progress
Suggestion: Add the dateTime when job started so user can gauge when job should finish and set expectations accordingly
For example, in our shop, a CI job should take around 20 minutes - but if you can;t tell when it started, you can't gauge when it will finish and plan your work accordingly
1 vote -
FogBugz integration for Gearset
We'd LOVE a FogBugz integration for Gearset similar to the new Jira Integration.
https://docs.gearset.com/feature-walkthroughs/integrating-with-jira
4 votes -
Provide the option to skip problem analysis
Sometimes during a complicated deployment I need to try a few different strategies to get things to work. For example, I may need to just send up one piece or set of metadata up first.
The problem is, each time I do this, I have to wait for problem analysis to complete, which takes a couple minutes. Normally during a deployment I do want problem analysis to run, but if I want to quickly send up a single object, I have to wait a few minutes while Problem Analysis runs, and the time waiting adds up.
Maybe a quick deployment…
6 votes -
Allow renaming of picklist values instead of creating new and deactivating
Currently, when you rename existing picklist values in the source org (including renaming the API name of that value), Gearset will deploy this to the target org as a new picklist value and deactivate the old value. This means we have to manually delete the value in the target org and specify which value to use to replace on existing records.
It would be great if Gearset could give the option to map a picklist value in the source to a picklist value in the target and allow a rename of the value in the target.
2 votes -
Allow "Rollback" if you have a user within the same org
Rollback currently requires the user who did the deployment to enable "Deployment" user access. Instead, it would be helpful if I could use my own user, within the same org, to do the rollback.
This would be helpful if the individual who did the first deployment is unavailable.
4 votes -
When source is local files, Refresh Comparison button should be smarter
If your source is Local files, and you do a Compare to some target, and then realize the source needs to be amended before re-comparing, your "training" is to clock "Refresh Comparison" button.
This executes but does not ask you to upload new source files so essentially nothing happens.
User should be given option to upload new folder/zip.
1 vote -
Issue with Namespace while deploying from Org A to Org B
the namespace if referred in code, we try to deploy to target Org, the target Org will not have the same namespace name, or will be a different namespace, it gives errors, can something be done to fix this?
1 vote -
Allow teams to share custom git repositories
It would be nice to be able to share custom git repositories with the entire team. At this time, each team member that does deployments needs to configure each custom git repo in Gearset. Besides requiring them to set it up, it also means I need to give each person the credentials.
4 votes -
Include a field's permission if the field is flagged as a missing dependent component
If a field is identified as missing from the deployment and the user agrees to include it, the corresponding field's permission should also be added.
4 votes
- Don't see your idea?