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.
1486 results found
-
Auto-delete stale and abandoned branches
It would be great to have an option to automatically delete branches (and their PRs, if there are any) that have had no activity for a configurable period, e.g., 3 months. This would help teams be more organized and efficient by reducing clutter. Currently, branches are deleted only when their PR reaches main or when both the PR and the branch are manually deleted. Stale or abandoned branches that never get promoted sit there and create a mess, and cleaning them up means manually checking for open PRs before deleting them in Git.
10 votes -
Search Error Monitoring by Record ID
Searching for an error by Record ID in the Error Monitoring tab instead of filtering to the process/flow that failed would be very helpful. Searching by Record ID is the one thing that makes using Flow error email still more useful for us, but we would like to move all error monitoring to Gearset.
5 votes -
Auto-delete feature branches only after final deployment. Current deletion can hinder troubleshooting if pipeline promotion fails.
The current "Auto delete feature branches when there are no PRs open against the branch" setting works well for general cleanup. However, in pipeline-driven deployments, a branch can be deleted even if the change fails to progress to the next stage.
Consider adding an option to delete feature branches only after the deployment successfully reaches the final environment (e.g., Production). This would preserve troubleshooting visibility when pipeline promotion fails and help teams investigate root causes before the branch is removed.
7 votes -
Audible Notification when Pipeline Updates have Deployed
The ask: an audible 'pop' sound (like the Support chat reply 'pop') when Pipeline updates are done processing
We have dev sandboxes, a Full sandbox, and production as our 3 layers to our Pipeline. When my personal dev sandbox gets really behind on updates, I hit errors when running ALL updates, so I do ~10 updates at a time. I fire up one wave of updates and navigate away from Gearset.
If I remember to come back to Pipeline in a timely fashion, it almost always is still processing. Or I often forget to come back to fire up a…
3 votes -
Deleted field references doesn't get auto-cleaned up in Layouts and ReportTypes
If a custom field is deleted, its references in Layouts and ReportTypes are not getting deleted in the environment branches. So each time, developer had to edit all the report types and layouts to remove the deleted field references. Imagine, this being done for hundreds of reportTypes in the system. If this cleanup is automated using Gearset, it would be more helpful for the developers.
17 votes -
Allow pre- and post-deployment steps for items that cannot be deployed through the Metadata API
We encounter a variety of user stories that require manual changes to items that cannot be deployed through the Metadata API. If these are the only changes required, there is no way to track these pre- and post-deployment steps, since a PR (and thus a metadata commit) is required to add the steps in Gearset.
3 votes -
Allow us to mark deployment failures on the pipeline as fixed without the need for a new deployment
When there was an error on deployment and we fixed it, by doing a compare and deploy. We would like to mark the Error as fixed. So other users can see that the error already has been solved.
2 votes -
Automatically detect drift between the org and main git branch
Currently we can automatically monitor and report on changes made to an org via the Change Monitoring dashboard. This compares an org snapshot to the previous days snapshot.
However, what would be really useful now we have pipelines enabled is the ability to automatically report on org drift from our Github main branch, using a specified filter (i.e. the same filter as our Pipeline CI Jobs use). This would allow us to track, understand and hopefully reduce the amount of drift that occurs in pipeline-relevant objects, making the pipeline more robust.
20 votes -
Expose all Gearset operations through APIs
Gearset can only be configured by a human through the UI. This leads to long, manual, and error prone setups with no way to create reproducible automation for common scenarios. We'd greatly benefit from having the ability to automate these setups through APIs or some Infrastructure as Code framework. Here are some examples of operations I'd love to automate or integrate into other workflows: initiate CI job PR validations, clear existing Updates from a developer sandbox, manage org connections, manage developer sandboxes in a pipeline, manage user permissions, manage monitoring jobs, manage unit testing jobs, mark manual steps as completed,…
2 votes -
Add the option to select specific metadata items before a back promotion fails.
We have multiple dev sandboxes. If there is a metadata item that is identified that should not be included in ALL back promotes, it's a waste of time for every dev to wait for this failure in order to remove the metadata item. Please provide an option to select specific metadata items before receiving the failure.
2 votes -
Body: When a Config Data / CPQ deployment fails or partially succeeds, there's currently no way to export the list of failed records and the
Body:
When a Config Data / CPQ deployment fails or partially succeeds, there's currently no way to export the list of failed records and their error messages. You can only review them on screen.For Metadata deployments this already works well — from Deployment history you open the deployment, click "View errors", and an export option is available there.
Please add the same export capability to the Config Data errors page. With larger data deployments, the number of failed records can be significant, and having the full error list in a file would make it much easier to triage the…
2 votes -
Notify When Metadata Is Not Enabled for Deployment
It would be helpful to have a warning/notification when metadata is added to a branch through a comparison but is not enabled for deployment.
We recently ran into a situation where the comparison allowed us to select managed package components and add them to the branch. However, the related metadata was not enabled for deployment, so those components were present in the branch but were not actually deployed to the target org.
It would be useful to have this notification either:
During comparison, when selecting metadata that is not enabled for deployment, or
When promoting the PR, if the PR…2 votes -
Commit test class selection
When initially creating a commit, the only way to specify tests is to manually create a comma or new line separated list. If the validation fails, there is then an option to add tests with a nice searchable/selectable list before revalidating. Can this test class selection UI be added to the initial commit process?
3 votes -
Quick Fetch Latest Changes
The quick fetch feature would just ensure that the components that already exist in that feature branch, are refreshed i.e. their latest version is fetched and automatically added to the commit with the click of a button, without having to go into the comparison view again, from which, now the user can create a new pull request.
2 votes -
Wrong deletion date for related record in the backups
Wrong deletion date for related record in the backups: due to full backup being done only once a week when we delete for example Opportunity, we can see only exact deletion date for it but even though it's related records are deleted at same moment, in the backups it's reflected only after full backup run.
1 vote -
Support reusable metadata filters for Monitoring jobs
Gearset provides the ability to reuse metadata filters across CI jobs which allows you to configure it once and have the changes apply to all jobs referencing it. https://docs.gearset.com/en/articles/618760-manage-custom-filters-in-ci-jobs
The same functionality is missing for Monitoring jobs. It would be very helpful if Gearset adds this feature for all existing and future locations where metadata filters are configured for a job.
1 vote -
Removing a dev sandbox from a group loses downstream environment connection
When you remove a developer sandbox from a developer sandbox group, Gearset "loses" its previous downstream environment connection. You need to edit the pipeline to reattach it to the environment to recreate the intended flow.
The sandbox groups should just be for organizational purposes, and that management shouldn't impact the actual pipeline connectivity for the sandbox. It's currently very easy to miss the lost connection which leads to a desync'd sandbox that's now missing out on sandbox Updates and manual deployment steps.1 vote -
Provide an easier way to cycle through all changes in a comparison
Gearset currently has arrows to cycle through the next and previous changes within a single metadata row. When you click the next arrow on the last change, it cycles back to the first change within that metadata.
I'd prefer the option for the next arrow to move you to the first change of the next metadata row instead of looping back to the top of the existing one. This is how Azure DevOps PRs works and it greatly speeds up the process when reviewing a large number of changes across multiple different metadata entries.1 vote -
Show manual steps in line with Developer sandbox Updates
Right now, the Updates UI shows all the pre/post deployment steps to the right of the individual commits while selecting what to back-promote to a Developer sandbox. We often have scenarios where a future commit will fail because a previous commit has a post deployment step that needs to be executed first. This causes the Admin to have to cancel the Updates and manual click through the commits to figure out how to break up the Updates based on the steps. I suggest that Gearset intermingles the pre/post deployment steps with the commits to more easily show where those steps…
1 vote -
Developer sandbox Updates seeding for Long-Term Projects
The Updates feature of developer sandboxes is very useful to keep our sandboxes up to date with changes flowing through our pipeline. We are running into an issue though when using it within a Long-Term Project. We've faced scenarios where we need to either refresh or create a new sandbox and integrate it as a dev sandbox feeding into the Long-Term Project's final static org. We have no easy way to catch that dev sandbox up to the current state of the static org because the metadata promoted there hasn't been released to Production yet.
It would be very helpful…1 vote
- Don't see your idea?