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.
294 results found
-
Ability to recreate a reusable list or group for Deployment notifications
Every week we have a larger sized scheduled deployment for logic updates that runs after business hours. There's usually the same 2-6 people (often increasing) that want to receive an email and/or text message when the deployment succeeds. Whoever schedules the deployment has to add each one manually every time, and it would be nice to have a way to send notifications to a predefined list or group of email addresses and/or phone numbers.
It usually has to be the person that schedules the deployment, because if someone goes back to add their own email or phone to an already…
5 votes -
When an Installed Package is installed via GS permission sets with View/Edit All Data system permission don't automatically get updated
When an Installed Package is installed via GS, permission sets with View/Edit All Data system permission don't automatically get updated for the new objects in the package like they do during a manual install. We then have to update the PS via deployment or manually or future deployments will fail with "Read All permission is required for [sObject]". I would think it would be fairly safe to allow GS to automatically add the appropriate object permissions to the perm set in the target org since Salesforce requires that all objects have, at minimum, the same level of access as the…
1 vote -
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 -
Add a deployed components count to the Deployment History table
We'd like the ability to view the number of changes that were deployed from the Deployment History table view so that we can quickly scan the list of recent deployments and identify certain deployments using that additional information.
1 vote -
resize column widths on "deployment history" page (no truncated values)
On the deployment history page, the column widths are fixed. If you have a value in the "friendly name" column that's over a certain character count, it gets truncated automatically. there is a tool tip to see the full value by hovering, but if you use consistent naming standards for naming deployment packages, this can result in having to hover over many package (i.e. rows) to find the one you want.
if making the column width customizable isn't possible, then making the "friendly name" column character limit longer would be a good start!
3 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 -
Change the Metadata Filters and make them first class
I would like to see a change to the metadata filtering in general.
Filter management has become a important part of our devops process as we seek to lower our comparison timing.
Instead of having it at the bottom corner of the compare screen, move that section to the middle of the compare screen.
In addition, add a side bar specifically for filters that allows you to edit or delete them as well as change the sharing between personal and team. I have example screenshots for suggested layout changes here: https://faef.box.com/s/frse8jnvqsxbl8ue05x641j3wlga1quy6 votes -
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 -
Delete comparisons
Be able to delete a comparison run with wrong filters or just keep the latest comparison
1 vote -
Delta only validation CI jobs
Idea is to have the Delta CI for Validation only Job, so the as well, so the validation process will become faster .
The option of validating a PR in the deployment job does the same task, but is comparing too many items of metadata and it is taking too long.
14 votes -
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 -
1 vote
-
I would like the ability to change filtered metadata to their API names
I recently had an internal business conversation to clarify what would and wouldn't be included in our new CI/CD process leveraging gearset to push to orgs. When we had this conversation we used the Metadata API names to discuss and then when I went to implement it in Gearset I saw that the filters are actually some translated 'friendly' names.
This is of course fine for most use cases, but it made it really difficult to make sure nothing is being missed when setting up the CI/CD filter type.I would kindly ask that you implement some switch to allow…
1 vote -
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 -
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 -
Hide irrelevant comparison types/components
After selecting the source org and viewing the metadata comparison filters, there should be an option to only show those types that contain data (the ones that have a number in parentheses). Or in other words... the ability to hide anything that isn't being used.
This would make it much faster to create new comparisons (or troubleshoot existing ones).
1 vote -
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 -
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
- Don't see your idea?