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.
1251 results found
-
Allow out of order Update deployment
Currently you can only deselect and select update elements in an order. For example I have 3 recent updates ordered 1 to 3. One being the oldest and first update and 3 being the newest and last update. The current functionality would require me to select item 1 if I wanted to also update item 2. And if I wanted to update item 3 I would have to select all the items before it.
I would like to select each one individual no matter there deployment history. Often I need to do this because the updates have no relation to…
2 votes -
Provide ability to link ADO ticket after a package has been validated
It would be great to be able to attach/link ADO ticket after a package has been validated. Currently we can only do it before click the validate button
1 vote -
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 -
Update Jira Status when linking to a ticket in Gearset
When a Jira ticket is linked to a branch in Github through Gearset, the status of the ticket could be automated (For example, we have statuses of In Development or Ready for Pipeline which could be used) to match further with the automatic status changes when the feature deploys through the pipeline.
1 vote -
Include CPQ Favorite objects in the supported objects
CPQ includes Favorite objects as part of the package but Gearset doesn't support them. These can be shared proactively with users so they don't have to make their own Favorites. We make these in a sandbox along with new CPQ product configurations and would like to be able to push these up to production along with the new configs.
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 -
Let "member" re-authorize team-shared orgs connections
In our Gearset setup, we have tens of "Team-Shared" orgs, both production and sandbox. Whenever any sandbox gets refreshed, its connection in Gearset needs to be re-authorized.
Currently, only users with "Owner" role have this "Re-Authorize" option. Users with "Member" role don't have this option.
This creates a problem for my team. Since my offshore team is supposed to do these sandbox refresh and re-authorization tasks, and they can't do it unless I give them "Owner" role, and thus giving them admin privilege over the entire Gearset.
Thus, I'm looking for a way to let a non-owner re-authorize salesforce org…
1 vote -
Deploy the Name of object without truncating
Hello,
I deploy from Sandbox to Prod.
I have a custom object where the Name is 42 characters long on the Sandbox.
When I deploy, it has only 40 characters on Prod.
If I run compare, 42 on sandbox, 40 on Prod.
If I deploy again, still 40 on Prod.
I can of course change the Name by hand on Prod to 42 characters.
Thanks
Stephane1 vote -
Add support to deploy Digital Experiences (LWR) using Digital Experience Bundle Components
Similiarly to how you can deploy metadata for non-LWR Digital Experiences (Aura templates), where you can select different metadata changes individually using Experience Bundle Components, rather than deploying all your changes at once, it would be great if that option is available for Digital Experiences running on LWR (Digital Experience Bundle)
1 vote -
Team members are able to create release with no access to CI job
Team members are able to create release with no access to CI job.
"Promote changes" is gray as expected, however "Create release" works which is awkward1 vote -
Allow customization options for the Deployment Report file name
It would be nice to either have the option to set a default file name or allow the ability to set the report file name in the deployment screen.
For my organization, this would make sorting deployment reports for various projects much easier as the file name doesn't include the Package Label.
2 votes -
enable using a Repository Access Token instead of a Service Account
I would like to be able to use a repository access token instead of a service account to connect to VC (Bitbucket in my case). https://support.atlassian.com/bitbucket-cloud/docs/repository-access-tokens/
The main benefit for me would be the ability to conveniently authenticate while maintaining a high level of security, even in situations where corporate change management policies and SSO requirements can be cumbersome.
1 vote -
Expand Permission reporting on the Monitoring job
Expand Permission reporting on the Monitoring job to include Delete permissions reporting on Objects.
2 votes -
Provide the ability to get a deployment report on multiple deployment packages
Instead of having to download the deployment report individually for multiple deployments, I would like to be able to select multiple deployments and download one report that contains a list of all files that were deployed as part of the multiple deployments. It is too cumbersome to manually download a report or .csv for each deployment and then copy/paste the info into one location so that I can get a comprehensive list of all files that were deployed.
9 votes -
Unsubscribe from commit emails
Choose to unsubscribe / subscribe from commit emails (success and or failures) in gearset setup in order to avoid generating unwanted emails (and their PDFs) for each deployment (and save a little CO2 along the way).
1 vote -
Have access to multiple pull request templates
Currently we can only access one pull request template named pullrequesttemplate from Gearset.
I would like to be able to access a list of templates.
This would allow us to have precise template for each team using Gearset.0 votes -
Improve visualization of multiple features being simultaneously worked on in a single developer sandbox.
Currently, one must select (or create) a single feature+branch in the developer sandbox. The pipeline view only shows 1 active feature at a time. It would be nice visually see all of the features an individual developer is working on/assigned to.
1 vote -
Gearset Pipelines Sandbox Environment
In order to test new Jira webhooks, GitHub actions, and any other release management changes,
We would like a Gearset sandbox environment where we could test release management changes like new/updates to Jira webhooks, GitHub actions, and other related changes.
1 vote -
Make the commit hash clickable in Pipeline PR Commits tab
This is rather trivial, but also seemingly a quick-win.
In the Commits tab on the Pull Request details screen in the Pipeline, make the 7-character commit hash a hyperlink that opens a new tab into github.
It is minor, would save me 1's of seconds, but it seems like an easy win - the commit url is just {{git-origin-url}}/commit/{{7-char-hash}}
2 votes -
Display pipeline webhook errors in Pull Request details
Scenario:
- Feature branch created, commits added, Pull Request opened and pushed part-way through the pipeline.
- Pull Request has merge conflicts on one of the environments. Conflicts are addressed, but (let's say) PR fails validation so it is not promoted.
- New commit is added to the feature branch.This commit will generally fail to propagate into the above mentioned PR branch (triggering a webhook error). It would be GREAT if that error were somehow displayed on the PR details screen.
1 vote
- Don't see your idea?