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.
1319 results found
-
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 -
Offer the ability to set the ignorewarnings flag on an individual "Compare and Deploy" basis.
Would like to see the ability to set the IgnoreWarnings as an override for an individual Compare and deploy, in addition to at the global level. Occasionally, we will do a community deploy, for example, that returns a warning about a page that includes a Dashboard component, with the warning that the Dashboard ID or the Filter ID might not exist in the target environment. Once we see those errors in the validation results, it would be convenient to rerun the deploy, and ignore those warnings. Possibly similar to how the Test execution options are set on the Deploy button…
3 votes -
Apply certain PA outputs back to the comparison as a "quick fix"
The main example where I have wished for this pretty strongly is the "missing permissions" PA. This is the one that warns "not all permissions are included in the deployment". It would be useful to be able to go from that PA to a view where one could either add all the missing permissions in one go, or do so selectively by profile or permission set. Right now one has to screen scrape the output, paste it into a text file, go back into the comparison and laboriously hunt through the comparison to find the missing nodes, then add them.
1 vote -
Change the Metadata Filters and make them first class
I would like to see a change to the metadata filtering in general.
Filter management has become a important part of our devops process as we seek to lower our comparison timing.
Instead of having it at the bottom corner of the compare screen, move that section to the middle of the compare screen.
In addition, add a side bar specifically for filters that allows you to edit or delete them as well as change the sharing between personal and team. I have example screenshots for suggested layout changes here: https://faef.box.com/s/frse8jnvqsxbl8ue05x641j3wlga1quy6 votes -
Granular "difference types to deploy" on a metadata level
In the CI job, we would like to have the ability to specify on a metadata level if we want to deploy new items, update items and delete items. There are examples of metadata where we always want to delete and others where we don't want to.
2 votes -
Create new branch using type-forward / auto-complete from JIRA (or other supported tool)
It would be great if you have JIRA connected, to make it easier to create your branch. So basically type-forward (-ish) functionality to identify a JIRA ticket and take the issue ID and description as branch name.
Say your JIRA ticket is ISSUE-1234 Implement this awesome feature.
The default branch name would be issue-1234-implement-this-awesome-feature.
(Where it reads JIRA could be Azure or any other support tool of course).
1 vote -
Include code coverage in deployment report
Hi,
I want to use the deployment report to monitor your progress towards improving the quality of our code.
So I need code coverage to be included in this report.7 votes -
Prevent Accidental Backing Out of Deployment components when Deploying Multiple Packages
Sometimes I have multiple packages that have been validated, that I am looking to deploy. If they happen to overlap components, then deploying in the wrong order could back out a change made by the earlier deployment.
From this I came up with two ideas that could help:1) The ability to select multiple validated packages or draft deployments, and click a button that will tell me if they have overlapping components. That will let me know if I have anything to worry about; if they overlap then maybe I should combine them into one package.
2) The ability to…
1 vote -
Option to ignore: <personAccountDefault> in XML
When comparing XML for RecordType permissions in Profiles, some Sandboxes return:
<personAccountDefault>true</personAccountDefault>As part of the XML, even though person accounts are not enabled, this makes comparing annoying.
It would be nice to have an option to ignore this.
10 votes -
Select All Option in Deployment history
It would be nice if we have the select all option in the deployment history to select multiple packages to combine in one go and deploy as one package into target.
2 votesThis is now possible as long as a filter is applied to the deployment history page.
-
The ability to deploy only certain fields in a record type and not all fields
If we want to promote a change to a single field in a record type, we're unable to because the file is pushed in it's entirety. We'd like the ability to view from list of available changes in a record type by field and select just the changes to the fields we want to promote.
3 votes
- Don't see your idea?