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.
190 results found
-
Auto merge of PRs
Once the validation process is successfully completed for the respective PR, it would be very helpful to have an option for automatic merge and deployment. This would streamline the release process and reduce manual steps.
Additionally, it would be great if we could have control at the org level to enable or disable auto merge functionality. This way, teams can decide whether they want to use auto merge based on their workflow preferences or organizational policies.
Thank you for considering these enhancements!
5 votes -
Feature Request: Deployment Blocking Based on Daily Unit Test Job Status
Currently, Gearset lacks a feature to block deployment CI jobs to the respective environments when the associated daily unit test job fails. Implementing this feature would be advantageous in ensuring that appropriate testing quality gates are established to prevent changes from being deployed in the event of test failures. This enhancement would significantly improve our deployment integrity and testing processes.
4 votes -
Deploy CustomLabel by label separately
The automated deploy (CI) filter does not have the resources to deploy isolated CustomLabels, so that specific labels can be included or excluded.
1 vote -
Adaption of Deployment frequency of CI jobs
While setting up a CI job, I recognized there are only automatization options up to every 24 hours, which is once a day. Currently there is no possibility to deploy e.g. every second day or even more important to us, every week/ every second week. Please add this possibility when adding CI jobs, to have a slower Deployment cycle to e.g. demo sandboxes, that don't need daily deployment.
1 vote -
Customizable Metadata Deployment Order - Destructive change and reference changes
We should be able to define the order of metadata deployments. For example, when deleting a custom field and updating its references, we currently need two separate deployments: one for modifying references and another for field deletion. Allowing us to set the deployment order—modified references first, then field deletion—would enable this in a single deployment, streamlining the process.
1 vote -
Install managed package from sfdx-project.json
I would like to get the possibility to track my managed packages and their versions in the sfdx-project.json file and automatically install it from this file. Could this be a possibility?
1 vote -
Add Omnistudio Features to Scratch Org Features list
When using the 'Create new scratch org' screen the following features are not available in the 'Scratch Org features' list
OmnistudioMetadata
OmnistudioRuntime
OmnistudioDesignerThese are available features according to the Salesforce documentation
1 vote -
Pull Request Changed Items View Fix
When viewing the items in a pull request in the 'Changes in this PR' section of the pipeline you only see the file name.
I would like to see something more similar to an actual comparison view where you have a tab with one column for the name and then another for metadata type.
Having just the full file name does not give me that instant information I need, especially when its a long file name and the type runs off the page never to be seen unless you hover over the file.
Converting to a table format might also…
1 vote -
Trigger CI Jobs on Gearset deployments
When setting up a CI Job originating from SFDC, we only have the option to trigger the job based on a time interval. Which makes sense since there are no events to subscribe to in SF for this.
But, I think it'd be helpful to be able to trigger a job to run on the completion of another Gearset deployment. This would be useful for automating the addition of metadata items like fields or layouts into source control, which are less-than-fun to create as xml files.
So rather than running such a job every 1hr, we'd ideally be able to…
1 vote -
Save Problem Analyzer Changes to Deployment Set
When using the Problem Analyzer to identify and fix issues within deployment sets, it's common to add or remove items to address specific problems. Currently, these changes are not automatically saved, which can lead to recurring issues in subsequent analyses.
Suggested Enhancement:
Introduce an option that allows users to save their modifications directly to the existing deployment set or create a copy of the set with these changes. This feature would streamline the problem-solving process and ensure that resolved issues do not reappear in future analyses.Benefits:
Efficiency: Reduce the time spent on re-analyzing and re-fixing recurring issues.
Consistency: Ensure…5 votes -
Option to create a CI job only for back propagation
We created some CI jobs for back propagation of changes from Production to other downstream branches and orgs. But these CI jobs also pick up pull requests(from a different pipeline) for forward propagation.
So, basically there is no way currently to create a CI job just for back propagation. It will be good to have a toggle in the CI job to mark it for forward or backward propagation9 votes -
Automatic sandbox updates option
The new sandbox updates process is really convenient - you can see all the updates a sandbox needs and apply one or more. However it is still very much a manual process to start it. We have a team of engineers and each one of them has to constantly go and trigger the update process manually whenever an update becomes available.
It would be really nice if there was a switch for 'Automatic updates' i.e. whenever it is turned on, the updates are applied automatically during off hours.
Of course if an update fails the engineer would receive an email…
3 votesThis is currently planned for later this quarter and next.
Users will have the option to:
- Bulk update selected dev sandboxes
- Automate developer sandbox updates; they will be immediately tried as and when ready
If users want to automate dev sandbox sychronization now, they can use CI jobs to deploy changes from their desired source of truth - this comes with some risk of affecting work in progress though.
-
Precision Deployments for Lightning Web Components
It is very much required to have Precision Deployment for LWC components as it is common to have multiple developers working on same LWC
4 votes -
precision deployment for Record types
precision deployment for Record types is required. currently when i try to deploy a record type gearset automatically adds all the picklist fields in that object. if we wanted to deploy only record type or only selected picklist fields currently its not possible. hence, precision deployment is needed for deploying record types
2 votes -
Add a Button to Retry Validation on Updates
The new Updates feature is great, but there isn't a "retry" button when there are validation errors to resolve. It's not very intuitive to have to cancel the update and go start over to retry after fixing validation errors. Currently it just shows that the validation failed and the update can be cancelled. It isn't clear what to do after resolving the validation error, and a retry validation button would simplify the process.
I had an error related to a manual change that needed to be enabled in my sandbox, and I had to cancel the update to get it…2 votes -
Quick deploy in pipelines
It would nice to be able to use the Quick Deploy feature once a release is validated, instead of either hitting deploy or scheduling the deploy and having it validate one again.
23 votes -
Job Completion Percentage
I would like to see more details about the status of a deployment or validation job in the Pipeline. Right now it just says job is running. I would like to see a estimated percentage of component validated/deployed against the total. Also maybe a running time estimate.
2 votes -
Create a queueing system for the new sandbox updates process
The new sandbox updates process, replacing long lived branches and back propagation in Gearset, is a really nice feature. However, it has limitations. I have found when trying to update multiple sandboxes at once using the updates feature, Gearset can only handle a couple before throwing an error and saying it is too busy and to try again later.
I have 6 sandboxes in the pipeline all using this feature so I have to start two, wait for them to update and then start the next two and so on.
If there was a way to set up a queueing…
1 vote -
Let "member" create team-shared CI jobs OR let owner convert member's CI job to team-shared
I see currently only team owners are able to create Team-Shared CI jobs. When my offshore team members who have "Member" role need to create a new CI job, their only option is creating a user-owned CI job, thus missing the benefits of Team-Shared CI jobs. All of our org connections are already Team-Shared. And we already have a Team-shared VC connection too. So, it'd have been very helpful if non-owner users with "Member" role could create Team-Shared CI.
Alternatively, if that's not possible, next best thing would be - if team owners could convert any member owned CI job…
1 vote -
Grouping developer sandboxes in Pipelines - back-promotion to a group
Team,
Currently Gearset Pipelines only offers the option to connect a developer sandbox group to a single downstream environment. While back-promotion to a group isn't available yetCould you please enable it ?
3 votes
- Don't see your idea?