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.
1405 results found
-
Show Metadata API version used to retrieve metadata for comparison on comparison result page
It would save time and give confidence if the specific Metadata API version number used to retrieve the metadata was displayed on the comparison results page.
2 votes -
Pull Request Branch Filter/restriction
Currently creating a pull request from the "Create pull request Screen" provides the user with a list of all the branches.
The default of this seems to be based on the last location you had selected when you created your branch (This usually ends up being main). As we have a pipeline this is the last place you want anyone being able to create a PR into!
It would be great if we could whitelist/blacklist a bunch of Branch names on this dropdown to stop users accidentally selecting main when creating a PR (for most users this would be one…
2 votes -
Indicate from Gearset if a deployment is eligible to use Quick Deploy
I would like to be able to see from Gearset if a deployment is able to utilize Quick Deploy. This would be particularly useful for releases to production as we release after hours and our unit tests can take many hours to run. Knowing that Gearset will use Quick Deploy will increase our confidence with our release and reduce mental load knowing that the deployment will be much more likely to succeed.
2 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 -
False error - 'Field permission cannot be set for Required Fields'
Deploying few field permissions through CI, there is an error 'Field permission cannot be set for Required Fields' in the Problem Analyzer, but actually the fields are not marked as Required in the target. Lead.Pronoun, Lead.GenderIdentity fields.
1 vote -
Expand the options for "Run job" times on the continuous integration job setup.
Currently the "Run job" option has times for 1, 2, 4 and 24 hours. With international teams working on projects, it would be nice to allow for something like every 8 hours. That could either be a new set option in the list, or allow for a "custom" option. If the pipelines can handle between 1 and 24 hours, let us selection "custom" and input the hours for the job interval to run.
6 votes -
exclude specific JSON keys when comparing Vlocity/Omnistudio metadata
We are seeing Omniscripts showing as different on certain JSON keys. These keys always change and should be excluded from your comparison.
The impact of this is Omniscript deployments require the LWCs to be compiled and if we deploy Omniscripts unintentionally, their LWCs are not recompiled and functionality breaks for the users.1 vote -
Flow equivalent of Static Code Analysis-esque rules
Code Analysis rules run against Apex in Gearset. As Salesforce development continues to rely on Flows as the main tool for declarative automation, it's becoming challenging to catch known inefficiencies, known issues, and discouraged usages. It would really set Gearset a part as a deployment tool to utilize issue detection or run "rules" against Flow metadata to call out potential issues or flows not following best practices to even prevent a deployment or commit from occurring.
Examples: SOQL or DML in a loop, the number of elements for flows (prior to api v57) or general overall complexity, lack of Descriptions…
4 votes -
Remove limitation of number of PRs to be added to a Release (Azure DevOps + Gearset)
Gearset automatically adds all PR details for a release in description box (Azure DevOps PR) which has max character limit of 4000 and only 16-18 PRs can be added to a release because of it. When we add one more PR after the limit is reached then the next PR does not get added to the Release and we need to create another release for them which is not correct approach as other releases may have some dependency on 1st and thing may fail in production. We need a way to disable adding description to Azure DevOps Release PR so…
2 votes -
Maintain version history for static code analysis rule set.
Need to maintain version history of static code analysis when creating a new set of rule ,who made the change , what was the previous version , what rules were there is previous version etc. Right now we cant even clone to create a new version and upgrade on top of it.
1 vote -
Add the ability to add "Shared Mailboxes" to "Deployment Notification."
It would be logical to have the ability to add a shared mailbox to the "deployment notifications" for individuals.
The current logic is that you need to add a user, however the only way to do this is create a SF user in a DEV org for the shared mailbox which is not clean or logical for a mechanism of a notification.
1 vote -
Limit who can connect Production or Specific Orgs
Our users may have access to certain orgs to do manual changes (we are working on reducing, but will probably never get to 0). Ability for us to block who can connect production can enforce usage of pipelines and prevent users from connecting their own user where they would get deployment access.
3 votes -
Salesforce Data Processing Engine metadata deployment
Enable the Data processing engine component deployment via Gearset. The metadata name is"BatchCalcJobDefinition"
1 vote -
Share edit access to a CI job with another user
Currently, only the owner of a CI job is able to edit it. This is a risk, as the owner is not always available to troubleshoot CI issues. It would be helpful to be able to delegate edit access to other team members so that pipelines can be managed collaboratively.
3 votes -
Microsoft Teams CI Deployment Job Notifications - Add Source Commit
There should be parity with the content included with a Teams web hook notification. With Slack, the Source Commit attribute is included.
With Teams, it's omitted. Please add so this data point is available with Teams. Current output illustration.
Slack
Gearset Continuous Integration
A continuous integration run succeeded for SIT Deployment / Validation job for PR #97. The job was a validation. No changes were detected for deployment.
Source commit
5ccc5b72Teams
A continuous integration run succeeded for SIT Deployment / Validation job for PR #97. The job was a validation. No changes were detected for deployment.
1 vote -
Fix CI PR Search Bar
The Search Bar in the CICD Pipelines appears to be using a custom matching logic that is awkward at best and outright misleading at worst. I start searching for a PBI with a term like '1093' and get 1 result, In then add an additional 3 to it ('10933') and am presented with 3 results, none of which have the term '10933' anywhere in them.
The algorithm appears to chunk parts of the search value and then 'fuzzy match' using each 'chunk' of string. So by adding a 3 to 1093, I was all of the sudden searching for all…
1 vote -
Add option to "run tests if X is present" on CI jobs
At the moment Gearset only offers an "all or nothing" option ("run all tests"), which is safer but completely ruins minor and cosmetic deployments (because it then takes half an hour to deploy even the smallest, inconsequent change like a Layout change) or "apex or nothing" option ("Default") which does allow for minor deployments to go through.. but also anything that's not Apex, which is dangerous because what if I'm deploying other automations like Flows? these changes would go un-tested.
At the very least an option for "run all tests if Apex OR Flow is present" sounds mandatory. But ideally…
4 votes -
Add api version check validation
We have experienced quite a few errors when a metadata component is developed in a sandbox that has been updated to the preview api version but production hasn't been updated to that version yet. Our entire pipeline and PR validation process works perfectly until the very last step when deploying to production. It's very difficult to deal with at that point.
3 votes -
Audit API - Production Filtering
From a compliance perspective, we only need to ingest production changes. It appears there are fields like 'SalesforceOrgType' on Anonymous Apex Endpoint and 'TargetMetadataLocationType' on Deployments Endpoint.
It would be great if we could filter those, even better if you could bring in Production Org ID / Name into that filtering ability and in response as well.
1 vote -
Deploy Now and Validate Package Buttons
Presently, the Deploy Now and Validate Package buttons are positioned adjacent to each other. Occasionally, there is a risk of unintentionally selecting the Deploy Now button before the package has been validated. This can result in potential issues arising. To address this, I recommend the following actions:
- Enable the Deploy Now button only after the Validate Package process is successfully completed.
- Consider repositioning the buttons within the User Interface if both buttons share the same screen.
- Alternatively, place the Deploy Now button after the Validate Package screen in the sequence.
Thanks.
1 vote
- Don't see your idea?