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.
1308 results found
-
When creating a Pull Request from Gearset have the option to default to another branche
After you did a deployment from a sandbox to GIT (Github in my case) you have the option to create a Pull Request right from that screen. The default target branche is "main" even though my default branche in Github is set to develop.
It would be great if Gearset follows that default branche that is set in Git OR has a way of defining default target branche in Gearset.
The risk now is that someone might overlook this, make a pull request against main, someone else also overlooks this and merges it into main. With CI jobs on main…1 vote -
Provide help link/button on each analyzer problem pane with specifiec discussion
Suggestion
In "Problem Analysis" page, the problems indicated and solutions are not necessarily obvious and understandable.The suggestion to read more about the analysers in the user guide is in the case I'm facing an enormous challenge.
Copy and paste the problem into your search mechanism brings back endless answers - not one used the wording in the problem statement!.
Here's an idea, have a button/link with each problem that take one to the user guide section (or other documentation) exploring the problem.
No hunting for answers as the 1st choice to figure out what your product is saying. It's…
1 vote -
Additional feature - GITHUB Pull Request validation in CI Job
Checkbox - Pull requests: Validate pull requests targeting the source branch is only visible when Run Job is set to --> Run tests based on Apex changes in the package
Request you to enable option even when this is set to Run Job: 1 / 2 /4 / 24 Hours
1 vote -
Add csv file results as attach
attach a file to Teams after code analitics with incoming Webhook
1 vote -
CI Deployment on a Schedule
We would love to schedule a deployment from GitHub source to a few sandboxes at the end of each 2-week sprint.
2 votes -
Add Comparison Column for "Environment"
Add a column for "Environment" which signifies which environment the change took place. For instance, this would tell you whether the changes took place in Production Only, Sandbox Only, or both.
Then, I could filter by Sandbox Only and both to see only the changes I made recently in the sandbox that I need to push to Production. Right now, I have to sift through the many little changes to items that occurred in Production.
1 vote -
Extend the functionality of configuring when are monitoring jobs run
Hey,
Currently it is possible to configure at what time during the day you we want to run the configuration jobs.For the org monitoring jobs, we really love that this is done daily, but for unit tests, we would love if we could configure the jobs to run the job weekly or monthly and not every day.
1 vote -
Allow the capability to deploy to multiple Salesforce organizations within one deployment
Currently you can only push to 1 Salesforce org, however, we manage multiple organizations and would like the capability to push the same package to multiple organizations
2 votes -
Add an Undo Action/Functionality in the Comparison UI
Add an Undo button to the comparison UI in case someone accidentally de-selects a component from the Selected Items tab. It would save time rather than having re-search for the component and lose your train of thought. You have this feature in Google Docs and sheets.
2 votes -
Send email alert when monitoring job fails
It would be helpful if Gearset would notify the user when connection problems cause a monitoring job to fail.
For example, if the error "Error while getting access token due to expired access" occurs, Gearset could send an email to the author of the monitoring job informing them of the problem.
3 votes -
Require Jira Updates for certain types of deployments.
While requiring updates on Jira tickets is nice we don't require this for ALL deployments such as if going to a production environment it's required however sandbox to github or sandbox to sandbox does not require an update.
1 vote -
Ability to mark(starring or adding to favourites) deployed package for quick reference
Once the deployment is done, if i want to clone the same pkg after 2 months, then its difficult for me to search through. Instead if there is any way to mark it by adding a star to adding to any favourite list will make it more handy and also available for quick reference.
1 vote -
Add option to make picklist fields non-restricted before performing a data deployment
Similar to being able to disable validation before performing a data deployment it would be very useful if there was an option to automatically uncheck the "Restrict picklist to the values defined in the value set" option for some or all of the picklist fields in a deployment.
We have data that includes picklist values that are no longer active this causes errors on individual records as part of the load. Currently I have to pick through all the errors manually then uncheck the option for the corresponding picklists fields on the target org. Then after performing the deployment I…
3 votes -
Ability to mark certain branches as your favorite branch so you can pick them quickly
When selecting a branch from source control, it would be great if Gearset had an ability to mark certain branches as favorites so they appear the top of branch selection dropdown.
3 votes -
sfdx repo deployment should be in subcomponents
Context: Compare and Deploy from Org to a Repo.
as i understand it, even if my repo is in SFDX format (Object subcomponents), Gearset still does the compare in the metadata format.
it reads the components from sfdx, combines into a .object form, and then applies the changes to the .object file and then decomposes again.this is causing unintentional changes to be part of our PR
2 votes -
Enhance Metadata Filter Type Recognition
Our team has struggled learning the Metadata API names of metadata types when compared to what items are called in change sets. One example would be to highlight Weblink when a user searches for Button.
3 votes -
Gearset configuration as a Code (git or exportable)
Gearset configuration as a Code (git or exportable) so that there is a way to store it i.e. in Git and see how various jobs, cicd pipelines, monitoring and schedulers are configured which is an enterprise way to implement solutions nowadays (PaaS, IaaS etc..)
2 votes -
Allow serial deployment instead of parallel
When executing a data deployment, an 'Unable to lock row' error can occur if multiple transactions try to lock the same record in Salesforce.
Because the batches are executed parallel, the chances of getting this error high, depending on the situation.
For example the master record in a master:detail relationship will always get locked when a DML is executed on the child record.
If two batches are executed at the same time and they both have at least 1 record that references the same parent, then a locking error will occur.6 votes -
Offer option to auto-limit items in clone comparison
When a deployment is completed, you have an option to clone that package. For many of my deployments, I want to push a package to source control, and then on to production. The second comparison could be limited to just the items in the cloned package. Would be great to have an option to limit second comparison to only the meta-data items in the clone. Would allow subsequent comparisons to run much more quickly, if the user is confident that the package has everything needed for that specific deployment.
1 vote -
Option to ignore package namespaces differences in Apex classes
Our Apex Classes reference multiple managed packages that are updated automatically in our sandbox/production environments. This causes many classes to get picked up unnecessarily in our comparisons/CI deployments between source control (where the managed packages are not committed) and org.
Unlike https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/43917792-add-an-option-to-ignore-package-version-difference this is specifically for different package namespaces between the source and target.
In this example the source has one namespace and the target has 2 package namespaces.
It would be very useful to be able to choose to ignore all package differences in comparisons and CI jobs as a team-wide setting.
1 vote
- Don't see your idea?