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.
329 results found
-
Export Validated Packages
Ability to Export Validated Packages from Grid, like Deployment History.
1 vote -
Ability for Enterprise User with Role "Owner" to Delete Validated Deployment by Other User
This feature would allow Enterprise user with Role"Owner" to Delete Validated Deployment by Other Users. The reason for doing this is that there could be packages created in error and this would allow release managers who are typically owners to cleanup.
1 vote -
Ability to select source target for Successful Deployment Notifications
Currently successful deployment notifications send every success to the specified addresses. Having the ability to specify the source would eliminate the unnecessary notifications to those addresses. We have a use case in which we only wish to send notifications for successful deployments to our production source.
5 votes -
Mass delete of deployment and validation history
Would like the ability to delete multiple history items at once. The current process of clicking delete and then clicking the confirmation is cumbersome and time consuming when we have multiple users and multiple environments kicking off many CI validations through the day. Failure to clean up the Validation history, especially, eventually brings Gearset CI viewing to a crawl. Having the ability to delete multiple at once and/or a the ability to add a retention period for history would be ideal. Validation history is the most important because you can't filter by time period like you can when you go…
5 votes -
Allow users to share deployment drafts across different Gearset environment
Lets say multiple vendors are working on different environments and done the deployment across all the lower environments using their own Gearset. But coming to the production org. internal team will be performing the deployments using internal Gearset. So Instead of recreating the deployment draft again, it would be very useful internal team can reuse the draft created by vendor in different Gearset environment.
1 vote -
add an account based autonumber field to deployment that could be used as a friendly reference
This could be automatically prefixed to friendly name of the deployment.
Sth like "000035"
Could be a simple counter (that I see you have implemented "This is your NNth deployment...").
If the autonumber would pop up automatically then I would not need to figure out a reference and type it myself.
Currently, info that potentially could be used: datetime (too long) , url (way too long)
2 votes -
Ability to Export SFDC Fields into a CSV File
Would it be possible to get a feature where we can download the fields into a csv file?
1 vote -
Show data hosting option chosen for an account
It would be great to see the chosen data hosting option for an account in the 'My Account' area. Without it security audits will not be able to verify what setting was chosen and will have to rely on documentation held elsewhere.
1 vote -
Bash scripting
Add support for bash scripting. This is one of the most powerful features of Jenkins and something that would make a huge difference in Gearset.
7 votes -
Limit Connections creation
Currently there is no feature to prevent users in creating their own connections within Gearset.
We need users to follow the permission that was setup on the shared connection. We have only 2 users that have the approval to deploy code from a sandbox to production. As they can set up their own connections then this bypasses our restriction
Having a permission only available to the Enterprise user or a user approved to create connections and delegate access would prevent the bypass of access permissions
3 votes -
Users should be able to specify test classes and save them to draft deployments
Users should be able to specific and save test classes in the comparison stage so they can be saved in draft deployments. Seems like a waste of extra steps to unclick tests and select tests over and over as you work through a deploy.
also when deploys are combined, they would get all the test classes, again, saving lots of time.
8 votes -
Support for WaveRecipe metadata is missing
There is no support for Wave Recipes currently and we are not able to deploy dashboards via Gearset and Continuous Integration.
4 votes -
Option to retry Deployment after failure
Currently, if your deployment fails you have two options:
- Click "back to results"
- Click "new comparison"
Going with option 1 means it needs to re-load the comparison and then click next and re-run all the analyzers again which can take a varying amount of time depending on the size of the comparison/deployment.
In situations where the deployment failed, but the fix is to change something in the org manually - it'd be great to have an option to simply "retry deployment" from the failed deployment screen and skip the various screens and re-loading.
3 votes -
Delete comparisons
Be able to delete a comparison run with wrong filters or just keep the latest comparison
1 vote -
Combine validated packages
Hi Team,
Please add checkbox for validated package as same as deployed ones. that way I can combine package even for validated one's and deploy.
10 votes -
Ability to return sub-components of a Profile from Source Control
Currently, profiles in source control are stored with everything as it's all stored in a single file (apex class permissions, layout assignments, etc). This is done by Salesforce.
When using the new "delta deploy" or any comparison that doesn't include every possible dependent component (ex. apex, layouts, etc) - you see many "new" or "deleted" items related to the fact that source control returns everything within the profile whereas Salesforce only returns specific permissions based on the retrieved components.
It'd be great if Gearset could replicate this behavior with source control to match Salesforce's behavior, where it'll obviously have to…
2 votes -
Validation Job to validate feature/* branch by scratch org creation
The idea is to validate feature branches in repo. For doing this it's necessary to allow specifying source branch by pattern (like feature/*) in "Add CI validation job" menu. The validation should check whether the code breaks the scratch org creation or not. This is valuable due to fragility of scratch org creation process (sfdx force:source:push).
5 votes -
Allow export of code coverage results in daily Unit Testing job
It would be great to be able to export the list of unit tests and their respective code coverage in a csv file for further internal processing.
2 votes -
Global Search feature
It would be very useful to have a Global Search feature within Gearset. This would be used to search the contents of all metadata objects.
My use case is that sometimes a string has been hardcoded inside a function. The only way to find the function that contains the string is to manually trace through the code. The global search would indicate the function that contains this string.
Another benefit would be to track dependencies for metadata objects that don't support dependency tracking. For example Aura Components, we could search for the component name.
12 votes -
Allow orgs to be grouped in folders
On the “My Connections” page, I'd love to see an option to add a folder (and sub-folders).
Currently, there are options for "Developer orgs", "Sandbox orgs", "Production orgs", and "Scratch orgs".
If you are running more than one entity, having the sandboxes related to a single entity inside of a folder would be more user-friendly than having multiple dev/sandbox orgs inside the same folder.
For example, if I'm managing deployments for "ABC Company", "XYZ Company", and "LMNOP Company", and each has multiple sandboxes, it would be really convenient to be able to separate out their various sandboxes more effectively, into…
2 votes
- Don't see your idea?