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.
1301 results found
-
Disable Pipeline Back-propagation for Static Environments
We would like to have the option to disable the back-propagation in the pipelines for static environments or have more options to control how the back-propagation should behave, like not running the PR validations for these types of Pull Requests.
When new changes reach the master branch, those changes should be pushed to the branch linked to a Salesforce environment. As it is today, the changes are back-propagated through new Pull Requests and because of the pipeline default config, the unit tests need to run which can block the sandboxes for some time depending on the complexity of the release…
3 votes -
Ability to report on runtime in Gearset Reporting API and what metadata filters were used
As part of showing the amount of time saved by using Gearset (and DevOps best practices), as well as the overall current utilization of Gearset across multiple teams and Gearset instances, being able to report on the Comparison, Validation, and Deployment runtime would be extremely beneficial. Also reporting on which metadata filter was used, if named and saved/accessible, in a comparison, validation, and deployment.
This data could also be used to identify inefficiencies in the standard metadata filters used across our Gearset instances, and potentially identify clients not deploying smaller and iteratively in order to prove with data how that…
5 votes -
CI job merger conflicts
When resolving CI job merge conflicts, a user has two windows to accept changes from one side of the window. Can we have an option to accept specific components changes from one side and certain changes from the other side.
4 votes -
Pipeline Sync Environment & Dev Environment
Currently we only have the ability to sync static pipeline environments. This is well and good but unfortunately syncing the Project branch can be time consuming and confusing Its not as simple as syncing the static environment.
I suggest when I sync the static environment , the sync action automatically opens a back propagation PR to the Dev environment its connected to. Also this sync action should close any pending open PRs against that dev environment that overlap with the sync PR.
2 votes -
Pipeline PR User interface Details
Currently we can see Jira ticket status when we look at PRs in the pipeline UI it would be phenomenal if we could include additional Jira fields to be seen from Pipeline UI such as Summary or fixversion
2 votes -
Add wildcard Test selection
When selecting tests to be run for validation or CI validation jobs, we should be able to select "Test classes" and provide more generic search names such as "Test.cls" or "classes/". This would allow dynamic updates to the selected tests based on available test in the deployment package.
1 vote -
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 -
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 -
[Data Backup] Allow field filtering on the Job History Search page
The ability to search for a specific record in the data backup Job History search tab is very helpful. As it exists today, you can search by ID or by Value - it appears that if you search by Value, it will try to find any record with that value on some subset of fields for the object chosen. However, if you have a very large dataset, the search takes an extremely long time to execute.
Here is a real world example for my company- we have Person Accounts enabled in our org and have about 9M records. More often…
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
- Don't see your idea?