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
-
Selectively filter managed package metadata without excluding unpackaged components
Add the ability to filter in/out managed package elements from a comparison set at metadata type level. e.g. allow for the comparison of managed package objects and fields but exclude other managed package metadata types whilst allowing those types to be available for non-packaged constituents. More specifically for instance, exclude manage package page layouts and include managed package custom fields whilst including both unpackaged page layouts and custom fields in the comparison set.
The reason for this is to minimise the comparison set which can reach limits due to size whilst including all mandatory metadata elements for a deploy.
Using…
4 votes -
4 votes
-
Allow changing of public group membership via Gearset
Right now, the only way to edit a group's membership is via the API (users or groups only) or the UI (additionally allows roles, roles and internal subordinates, etc.). Please allow the editing of group membership of public groups.
4 votes -
Restrict source orgs
For example, deployments to a production environment should only come from the master branch of our git repository
4 votes -
Allow multiple team members to be assigned to a single sandbox on the pipeline view
Currently a single team shared sandbox can have multiple users with delegated access. However, only one of the users can view the sandbox in a pipeline view. In order to allow multiple people to see the sandbox -
Current solutions:
- Add the same sandbox multiple times and assign each to the required team members
- Or, allow all team members to see all sandboxesSuggested solution:
- Allow multiple team members to be selected via the "Assign sandbox to team member" function.3 votes -
Ability to Select and Merge Specific Changes in Lightning Components and Flows
We are using Gearset to compare and merge changes in Lightning and Aura components, as well as Salesforce Flows. While the tool works well overall, we’ve noticed that it currently lacks the ability to select and move specific changes during a merge. Instead, it requires replacing the entire file, which isn’t ideal in many cases.
It would be extremely helpful if Gearset could allow selective merging of specific lines or sections—similar to how it works for Apex classes. This feature would greatly improve control and efficiency when working with Flows and Lightning components.
Thanks for considering this enhancement!
3 votes -
Pick up test classes to run from the apex class
Add a variable in apex classes where we can specify which test classes to run.
Recently you added the ability to specify the test classes to run on a pull request, which is great!
I know <ApexClassName>Test are automatically picked up by GS, but would be great if we could specify with
@TestClasses('CaseTestSuite,LeadTestSuite') or similar in the actual Apex Class and Gearset would automatically pick it up and add those test classes to the pull requests .3 votes -
Make pre/post deployment steps conditional on developer sandboxes.
Pre/Post deployment notes can be set to pertains to various static environments but they always apply to sandboxes after a back deploy. This should be conditional-- most of the time I only set them applicable to prod and they aren't applicable to developer sandboxes.
3 votes -
It would be great to have a centralized way to view all components and static code analysis results for every commit within a branch.
It would be great to have a centralized view for all components and static code analysis results across every commit within a feature branch. For example, if a developer makes five commits to the same branch, it would be much more efficient to review the components and static code analysis results for the entire branch in one place, rather than checking each commit individually through the deployment history. Additionally, there should be an export option to easily share the results with developers. Thanks
3 votes -
Mass resolve auto resolved conflicts
Currently we have the auto resolve from previous environment feature which takes previous conflict resolution into account for a new conflict dectection run in a new environment. This is great but if I am deploying through a pipeline to multiple ORGs and the same conflicts that are auto resolved each time popup I need to keep clicking through them and marking as resolved.
I would like there to be a Mass resolve button that only resolves all the auto resolved conflicts. That way I dont have to click through each one even though everything is resolved already.
3 votes -
allow automatic publishing of an experience site after deployment
Just like you can automatically activate Flows in Gearset upon deployment; it would be nice to automatically publish deployments of Experience Bundles. This is especailly true for deploying Experience Bundles to staging/qa orgs but applies also to PROD.
There's an API to do this: /connect/communities/communityId/publish documented https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_communities_publish.htm
3 votes -
Provide deployment options for Mulesoft via Gearset
As Gearset does Salesforce based deployments so well, it would be great to have Mule deployments done through Gearset as well.
3 votes -
Provide and enforce branch naming conventions
Branches get all kinds of really stupid names over time. It would be nice if Gearset provided an option to template new branch names. For example when my users need to create a new feature branch for their user story, Gearset should prefix that branch with 'feature/'. When a release branch is created it should be prefixed as 'release/'. Bugfixes or Hotfixes could be bugfix/ or hotfix/.
Dictating naming conventions is unenforcable. Keeping branch names organized goes a long way to keeping the repository maintainable over long periods of time. Even if folks are well intentioned, git branches are case…
3 votes -
Make Gearset more responsive via web design
Currently when doing deployments I have realized when i migrate to a smaller screen that gearset isn't super responsive and sometimes i have to drag it back to my larger monitor. This was really highlighted when I was attempting to deploy some metadata from my phone (mac was updating).
Please make gearset more responsive so I can deploy from my phone.3 votes -
Require a Deployment Friendly name
Add option to require a Deployment Friendly name, similar to the current settings to require deployment notes and Jira tickets
3 votes -
Automatic Validation of Pull request for AWS code commit
Gearset does not support PR validation for AWS code commit. We are cloud-native and use AWS extensively, thus missing out on most important feature of gearset. If you can support it it will be amazing and lifesaver for us.
https://gearset.com/blog/set-up-automatic-validations-of-pull-requests/
3 votes -
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 -
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 -
Limit Connections creation
Currently there is no feature to prevent users in creating their own connections within Gearset.
We need users to follow the permission that was setup on the shared connection. We have only 2 users that have the approval to deploy code from a sandbox to production. As they can set up their own connections then this bypasses our restriction
Having a permission only available to the Enterprise user or a user approved to create connections and delegate access would prevent the bypass of access permissions
3 votes -
Custom ordering option for CI Dashboard
Rather than splitting jobs into Validate and Deploy and ordering alphabetically, allow custom ordering (drag and drop, or custom grouping) in order to maintain logical job sequences including a mix of deploy and validate jobs.
3 votes
- Don't see your idea?