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.
1235 results found
-
Allow download of the zip package for failed CI jobs
Download the Gearset constructed package from CI job history when the CI job failed
1 vote -
Categorize Meta Data Filters
Allow the custom meta data filters to be categorize or put in folders. You could organize your filters by customer, deployment type, etc..
4 votes -
Create Change set without comparison
Allow user to directly create a change set without doing the comparison. If user has a list of items that needs to be migrated then allow the user to add items and skip comparison step.
25 votes -
Provide controls around who can create/manage Salesforce Connections
I have a team of multiple admins that use GearSet and I want to fully control who can deploy where. I can set this up with security today in GearSet by what kind of access I grant. However a user can create their own connection using their credentials and get around the shared connections I have established. I would like the ability to disable a users ability to create new connections which would then only allow them to use pre-existing connections that I have established appropriate security for.
1 vote -
Stop the reordering of XML when deploying to git
At commit to branch, Gearset reorders large chunks of the XML file. This causes additional deltas (seen in the hundreds of lines) and merge conflicts.
30 votes -
Include Apex classes imported into LWC
Ensure that Apex Classes imported in LWC javascript files are included in dependencies.
2 votes -
Provide integration with WebexTeams
We moved from Slack to WebexTeams and have lost the ability to post deployment notifications from Gearset. Here's an article about Webex Bots: https://developer.webex.com/docs/bots.
3 votes -
Warning On Missing Custom Metadata Field
I had a deployment fail today due to a difference between a custom metadata type's definition in the source org vs the destination. The source had two extra fields that the destination did not have. This cause the metadata record deployment to fail, because two extra values were included in the deployment which did not have corresponding fields in the destination. Because the fields were for a custom metadata package, I was unable to (easily) add the fields into the destination org.
I'd like to see a way to suppress custom metadata values. This may be solvable through the inline…
1 vote -
Warn about Email Deliverability setting
Warn users when they are about to deploy (data OR metadata) to remind them when "Email Deliverability" is turned on.
1 vote -
Ability to Compare metadata filters
When we have too many metadata filters, it is getting hard to keep track of them and figure out the similarities between them. It would be great to have an option to compare custom metadata filters.
2 votes -
Allow deployment of Email header/footer changes
Examine changes to Email Footers and allow deployment of changes.
1 vote -
Add 'run selected tests' in nightly scheduled Unit Tests Jobs.
We can select which tests run in Validation. It would be great if we could do the same in a nightly monitoring job.
2 votes -
Find/Replace before deployment
Allow a basic find/replace to run against files before final deployment.
Examples: a username that would work in the sandbox that does not exist in production and we need to change it. Or deploying to a packaging org required a modification due to various namespace issues. Other tools have a means to do this in one way or another.3 votes -
View Grouped Successful, Validated, and Monitor Jobs per Instance in List
Our organization has now done over 13,000 deployments (yay!), but that means when I have to search for past deployments, any searching beyond 10 days as the filter becomes an impossible task because of the sheer volume that has to be searched (boo).
When trying to combine successfully deployed packages into a new package, if I have to change the date range to find a deployment done several months ago, I lose the selected deployments from a more recent timeframe and can't select them all to combine neatly.
If we could see successful deployments by viewing the authorized Org in…
9 votes -
Allow date range filtering on the "Changed On" column
Currently one has to pick dates individually, if one has 30 + dates to select, this can be massively simplified if one could select a date range.
13 votes -
Save deployment analysis suggestions and list of test classes
In order to make deployments more repeatable between orgs please allow a way to save the selection of deployment analysis suggestions an d list of test classes with a package. With a large package it can be difficult having to document or remember the same selections used in deployment to UAT org for Production deployment.
5 votes -
Changed by and Changed Date not populating from DX structure in Repository
Using the DX/source structure in a repository (Github), no "item changed" date is shown for any metadata types in the comparison window.
This leads to gearset not being able to provide last changed date or who last changed anything in a Source DX repository. It's left with "unknown" and makes our comparisons and selections more difficult when users rely on that information.
1 vote -
facilitate selection at the UI of related permissions for selected items during deployment
Our typical use case surrounding related permissions for selected components (application visibilities, class accesses, field permissions, layout assignments, object permissions, page accesses, record type visibilities, tab visibilities) is to need to ensure that if a component is selected, its related permission is always selected also, with respect to a target set of profiles. We suggest you provide an affordance at the UI that selects related permissions en masse rather than requiring individual mouse clicks for each permission selection as at present.
2 votes -
Allow CI deployment notifications to the specific user who made the source control commit that prompted the deployment
We have CI jobs that fire on commits to a source control repository. At the moment, there is no way to email the specific individual who made the commit that prompted the deployment, so we have to notify everyone involved in the project whenever a deployment fails. If we could just notify the individual who made the commit (plus the deployment manager), it would reduce noise considerably.
Please add this feature.
13 votes -
Separate the Custom Settings <object> Permissions and Metadata Type permissions from the Profile or Permission set
When promoting Custom Objects and their security, we have to look at Custom Object Permissions (after loading the respective Profiles and Permission Sets in addition to the Custom Objects). We should follow a similar model for Custom Settings and Custom Metadata Types. The reason is that, if they remain part of the Profile or Permission Set, then I have to make sure that the Profile or Permission set exactly matches what I want in the target environment - I can't have any extra Custom Settings or Metadata Types that don't exist in the target environment yet or the promotion will…
1 vote
- Don't see your idea?