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.
1357 results found
-
Add the ability to create some custom reporting against metadata change monitoring
I would like the ability to report on changes for an org over a time period grouped by metadata type or user. Filters would be by data, user, metadata type, change type. Would like to export or email the report too.
1 vote -
Mass deletion of data from backup
We want to know how to automate the deletion in backup system.
Common use case is deletion of customer data due to legal compliance.
1 vote -
Metadata Filter organization with group or tag management
It's great that we can set filter visibility now to Only Me or to share with Team. It would be nice, especially for larger teams, to have another way to organize them either with tags, folders, sub teams or groups.
Example: 1 Scrum Team may have 10-15 filters they maintain and use, and another group of users on a team also have 5 or so they use. Both can see all 20, and this adds up fast.
Feels like being able to group users together could also have other benefits like mass assigning access to orgs (for deployment, validation, comparison)…
5 votes -
Add ability to clone deployment CI job to validation-only CI job
This would save us time duplicating regex statements for the new job
6 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 an option to disable Problem Analysis for CI
When running CI jobs, we can create a problem analysis template to control what potential problems can block a deployment.
For deployments from SF orgs to Git, many of the problems being analysed are just irrelevant (e.g. users don't exist in the target, because the target is not Salesforce).
Although some options can be switched off via templates, the list is not comprehensive. So, it would be great to have an option to switch off everything, or a built-in template of "no analysis".
When production is the source of truth, we just want all the metadata to get copied into…
1 vote -
Make metadata filters easier to use when you want to "include all except X,Y"
For CI jobs, it is not uncommon that you want to include all elements of a given custom metadata type except specific elements
Today, you need to have two entries - an include all (".*") expression and an exclude expression. For users who are not regex savvy, this is too complicated.
We should have "All", "Named", and "All except Named" at the top level so simple check boxes can be used.
This is particularly useful for CI jobs (whose purpose is to sync VCS w/ org) - you want to sync most everything except a few items - like Sites…
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 -
Add ability to disable all comments on JIRA tickets
Currently, when adding a ticket number in JIRA connector on a deployment, there is no possibility to disable comments sending on JIRA.
This can be a problem, as JIRA tickets can also be seen by our final users, and this "XXX has deployed the ticket" kind of comments can question them.
4 votes -
Allow Package Cloning between Saved Comparison Pairs
Please allow us to select a comparison pair as the source/destination when cloning a package. This will make it much easier to select the source and destination when cloning a package, and reduce the risks associated with accidentally selecting the wrong repo or branch or sandbox.
2 votes -
Add a filter in monitoring job to exclude changes done by Gearset
To help identify changes done manually to the org it would be nice to have a filter which excludes all the changes done by Gearset deployment.
2 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 -
Add the ability to order/chain overnight jobs
Gearset offers various automated jobs that run overnight e.g. Org Monitoring Snapshots, CI Jobs, Unit Test Runs.
it would be great to be able to set an ordering on how those run for any particular org. For example, a natural order for the night jobs may be:
- Monitoring Snapshot
- CI run
- Unit testing
This means we have a backup before making any potential CI changes and the unit tests show the results after CI. It would also allow us to make sure that the jobs don't clash.
Ideally, we'd be able to do this without just specifying exact times to…
2 votes -
Choose Delete action per Metadata Type for CI jobs
In the past we had troubles deploying reports via CI, they were not showing/deploying, the workaround was to enable the filter to include all reports. This works to solve that, but now I am looking at including more into the repo and start using delete actions in the CI jobs as well. The downside is that because we have to have all reports in the filter, the CI job will delete reports created by users in non-private folders. A freedom we want to give certain users in Production.
What would be an epic enhancement (and solve this challenge) is if…
27 votes -
Apply masking of certain data across backups GDPR compliance
It would be great if records that were marked with certain GDPR attributes, possibly 'GDPR Removal = TRUE' that the backups could apply arbitrary data masking across all historical backups for email and phone number fields
2 votes -
Microsoft Active Directory authentication for Gearset
Our company works with Microsoft tools and it would be very useful for us to be able to authenticate with Microsoft Active Directory. That way our security team only has 1 place to manage users for all our tools.
4 votes -
Deploying from SF to Repo with unlocked packages can result in items deploying incorrectly
When deploying from SF to a branch that has the force-app and unlocked packages, if you deploy an item that would include the object file it deploys to the unlocked package directory instead of the default app listed in the project.json. The end result is everything related to the object is moved from the force-app to the unlocked package directory.
Steps to recreate:
Enable source tracked sandboxes
Create a new dev sandbox
Create a new branch and link it to the new sandbox
Create a new field on Contact
Edit a search layout on Contact
Use gearset to deploy the…1 vote -
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
- Don't see your idea?