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.
1361 results found
-
Empty cache during meta deployment process
Before you deploy but after you start the process it should be possible to refresh / empty cache to make sure that any updates to the meta data in either source or target are updated.
3 votes -
CI/CV job archiving
Create a mechanism by which CI and CV jobs can be archived, but not deleted. Sometimes there is a job that is not used, but the history needs to be kept for some period of time.
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 -
Allow for cross-object mapping with the data deployment add-on
It would be so powerful to allow users to map data to different objects using the data deployment tool. It would allow us to move data efficiently between orgs that don't have completely aligned object APIs and metadata.
3 votes -
Users should be able to specify test classes and save them to draft deployments
Users should be able to specific and save test classes in the comparison stage so they can be saved in draft deployments. Seems like a waste of extra steps to unclick tests and select tests over and over as you work through a deploy.
also when deploys are combined, they would get all the test classes, again, saving lots of time.
8 votes -
Last Modified in Metadata Filter
It would be great if I could set a "last modified" filter when setting which metadata to pull. Rather than go to Apex Classes, wait for the list to refresh, then cherry-pick them, it would be great to simply compare Apex classes modified today, or in the last 30 days, or in the last hour, etc.
4 votes -
Support for WaveRecipe metadata is missing
There is no support for Wave Recipes currently and we are not able to deploy dashboards via Gearset and Continuous Integration.
4 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 -
Improve error message when XML is not properly escaped
When I choose to compare metadata with my source as my VCS, there was an "&" char in the recordtype XML definition file.
<values> <fullName>Food & Beverage</fullName> <default>false</default> </values>This threw an error and there was no support and no explanation at that time.
I suggest you to improve this error message.
Message I got:Could not parse the XML for 'force-app/main/default/objects/Lead/businessProcesses/Buyer.recordType-meta.xml'. Error occurred at line 71. Further details: An error occurred while parsing EntityName. Line 71, position 29.
File, line and position it's ok. maybe a link to Gearset docs with walkthrough with this probable cause when a parsing…
1 vote -
Delete comparisons
Be able to delete a comparison run with wrong filters or just keep the latest comparison
1 vote -
Ability to choose whether or not to respect the forceignore file
Would like a checkbox on the comparison screen that allows me to choose whether or not the comparison will respect the contents of the forceignore file. (Similar to the checkbox allowing you to choose whether or not the comparison should use the package.xml file).
Our usage of Gearset does not align with our usage of the forceignore file for automated deployments. In fact, we often use Gearset to manually compare and/or deploy items that we specifically ignore for automated deployments.
Summary of problem this new feature has introduced:
We use gearset for org -> git deployments, and for git ->…5 votes -
Need to have JIRA integration with Data Deployments
Need to have JIRA integration with Data Deployments which will improve the process and allign it with meta data deployments
2 votes -
Add Salesforce ID to Export History button
Can you add the Salesforce ID to the Export History button for reconciliation purpose.
We currently have to manually match the Salesforce ID in Gearset with the Salesforce ID on the Salesforce Deployment Status page to get the reference between the source ticket in Jira and the deployed change for compliance purpose which is a time consuming process.2 votes -
To give the option to export , Class wise test coverage report in some Excel format
To give the option to export , Class wise test coverage report in some Excel format
3 votes -
Combine validated packages
Hi Team,
Please add checkbox for validated package as same as deployed ones. that way I can combine package even for validated one's and deploy.
10 votes -
Ability to return sub-components of a Profile from Source Control
Currently, profiles in source control are stored with everything as it's all stored in a single file (apex class permissions, layout assignments, etc). This is done by Salesforce.
When using the new "delta deploy" or any comparison that doesn't include every possible dependent component (ex. apex, layouts, etc) - you see many "new" or "deleted" items related to the fact that source control returns everything within the profile whereas Salesforce only returns specific permissions based on the retrieved components.
It'd be great if Gearset could replicate this behavior with source control to match Salesforce's behavior, where it'll obviously have to…
2 votes -
Add additional controls to Monitor
Hello Gearset,
We are exploring using the "Monitoring" functionality to audit our Salesforce production metadata changes for our IT Controls. It looked promising until we found out that anyone on the team can edit any monitor job setting, which creates a loophole in the controls that we can't monitor the monitor.
So I'm curious to learn from Gearset whether any of the following can be done/requested:
* Can we limit the Monitor jobs to only be editable by the person who created it?
* Can we show either an audit history or LastModifedBy/LastModifiedTime of the Monitor job?
* If the…4 votes -
Gearset should control the order of deployment for Report Types, Reports and Dashboards
Dashboards require Reports, and Reports require Report Types. Yet when I attempt to deploy a group of components that comprises all of the necessary components, I'm hit with errors that the required components don't exist <yet>. That shouldn't happen. This is going to <artificially> require me to do multiple deployments. :(
3 votes -
Validation Job to validate feature/* branch by scratch org creation
The idea is to validate feature branches in repo. For doing this it's necessary to allow specifying source branch by pattern (like feature/*) in "Add CI validation job" menu. The validation should check whether the code breaks the scratch org creation or not. This is valuable due to fragility of scratch org creation process (sfdx force:source:push).
5 votes -
Ability to cherry pick changes in a file
When comparing changes between a source org and a target org for a given file/metadata component, it will be great to have the ability to choose which change(s) should be promoted from the source org to the target org.
Presently, it's an all-or-nothing scenario i.e. either one deploys all the changes to a given file from source to target or deploys none. As a workaround, we cherry pick changes to a file using VSCode and then deploy to the target org using VSCode –– which is the exception to our "all metadata changes must be deployed through Gearset" policy.
Adding…
5 votes
- Don't see your idea?