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.
1373 results found
-
SFDX projects and source format and CLI useage
Gearset CI only supports SFDX source that follows the SFDX project template structure (e.g. force-app/main/default/classes and so on). However, SFX CLI doesn't mandate that structure.
SFDX allows you to group metadata by function or logical group (so you can combine metadata in any way that makes sense to you) . We have many projects like this that gearset cannot deploy.2 votes -
Checkboxes to delete multiple packages/validations/deployments at a time
Hi - feature request:
Checkboxes on the validated packages (and probably others) screen so that I can delete validated packages more quickly. One by one is a big pain, and it probably uses your storage... and it definitely clutters our workspace.
Thanks!2 votes -
Create a persistent default setting for Monitoring Job Notifications
It would be nice if there was a way to default the notification for monitoring jobs to 'send notification only when changed'. Right now, if you set monitoring, you get an email a day from that job, regardless if there was a change or not. You have to manually change it otherwise.
Nice to have that setting front and center, available when you select monitoring, as well as have a default value for each org type; Prod, Sand, and Dev.
2 votes -
add the ability to filter Git repos on connection
It would be useful to be able to select only applicable Git repos from source control that will interact with Gearset. A user may have many repos that they need on their account, but of those there may only be 1 which would be used via GearSet. It would be great if we could select which repos should be available when setting up the connection to our source control (specifically I am requesting GitHub but I think this would be useful for all source control integrations).
2 votes -
Display Permission Set changes as one entry
When working with Permission Set changes, it sometimes would be useful to see them grouped by Permission Set instead of being disaggregated by field. For example, we are migrating from using Profiles to Permission sets to grant all access. Currently, if we make changes to many (>100) fields in two different Permission Sets, we have to review many (>100) entries. Also, grouping by permission set would allow us to deploy changes to one Permission Set while ignoring the other.
2 votes -
Connection List Search Feature
Add a Search feature to Connections Page. I have 59 connections at the moment and the only differentiation between them is a suffix at the end of the login. It would be nice to be able to quickly search the list of Connections like a CTRL + F would do.
I often have to scroll the list and compare login usernames.
2 votes -
Problem Analyzers don't evaluate changes made from other Problem Analzyers
Even though this example has an easy workaround, it does seem like a scenario which could present issues in other deployments.
In the scenario where a standard application that doesn't exist in the target (ex. Sandboxes and LightningInstrumentation) is included in a deployment (along with its permissions), there's 2 problem analyzers that come into play
"Remove standard application additions/deletions from deployment"
"Remove items which reference the listed components which are not available in the target"
When both metadata types are selected (application and permission) only #1 is flagged. This means Gearset removes the standardApplication, but leaves the references to the…
2 votes -
Add support for deploying a name change to a SFDC component (such as profile)
We occasionally change profile names during permssions clean-up projects. Currently, when you deploy a profile with a changed name, Gearset recognizes it as a "new" and a "deleted" profile, instead of a single "changed" component, which makes the deployment challenging.
I know that the name is used as an identifier, since the Id may not always match between source and target. However, if you add support for this, the tool could try to identify components with name changes by looking for the same Id in source and target with a changed name.
2 votes -
Allow Source to choose multiple Branch for CICD Validate/Deploy
when choosing source as GitHub it allows user to choose feature/*** which allows every commit on branch name starts feature will trigger the CICD
2 votes -
Deploy on pull request creation
Currently is supported only validation on pull request creation. It would be great if we can also do deployment on pull request creation, not only on merge.
2 votes -
Remember last used repository and branch for Azure DevOps integration
Remember the last used repository and branch in all places.
2 votes -
Spacing in formulas
This was marked as completed in https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/34690018-preserve-spacing-in-formulas but seems to be broken again. Formulas or criteria in WF are deployed without carriage returns, which makes formulas very messy to work with.
2 votes -
Need a Integration of Gearset & Jira , once the user story is updated in Jira , My gearset job will get triggered
Need a Integration of Gearset & Jira , once the user story is updated in Jira , My gearset job will get triggered and deploy the components related to that user story.
and once the deployment is done , update the jira ticket status as deployment done.2 votes -
mark destructive only changes as a separate difference
due to deployment limitations with salesforce destructive changes destructive changes dont necessarily reflect branch to org so these deltas are being marked as differences even though there is no way to fix other than manually in the org. these should be marked as a separate difference type for easier filtering.
2 votes -
Send different deployment notifications based on the target org type
Successful deployment notification is for all sandboxes. It would be nice if we can have a separate notification for production and sandboxes as certain people only care what goes to production. Thank you!
2 votes -
Support for WaveXmd metadata is missing
If we replace default DataSet in Einstein Analytics, it creates another type of metadata "WaveXmd". Support for the deployment of this metadata is missing from Gearset and as per discussion with Gearset team, it's a bug. Could you please fix it.
2 votes -
Show In-Progress Validation jobs when clicking 'Details' in GitHub PR
When viewing a GitHub PR and you have a status check that's in progress, clicking 'Details' should take you to the validation only job page and show all validations (including those in progress).
Currently this page only shows you completed validations which makes it confusing to use at first and you have to navigate to 'Continuous Integration' and find the validation job there.
2 votes -
Display more workflow subcomponents under Workflow for Metadata filter
Currently, two sub-components display under Workflow when selecting metadata types within a filter.
- WorkflowAlert
- WorkflowRule
There's more sub-components than those two and I'd argue that there's two that are frequently used that should be included for visibility
- WorkflowFieldUpdate
- WorkflowOutboundMessage
There's 2 more, but these may be used less frequently and not needed for visibility
- WorkflowKnowledgePublish
- WorkflowTask
2 votes -
Github: Ability to select Reviewers for pull requests created in Gearset
Currently, you can create a PR after a successful deployment in Gearset. You're able to provide a description and even select it as a draft.
However, the only potentially necessary field that's missing is "reviewers". This means any CI/CD setup you have that requires an approval requires the user to go into Github just to add the reviewer.
Since Gearset would have all the team members (and those with linked github accounts), it seems it might be an opportunity to select based on that list and pass the linked username on to github in the PR creation to keep end…
2 votes -
Show/Flag what unlocked package elements are getting updated on Monitoring Jobs
When you look at the details of a monitoring job there is a field called "Packages Afftected" that shows green when is 0 and orange when >0.
There is a description that says...
Unlocked packages have been modified. View the comparison to see details.
However, when you look at the details there is nothing there to see what unlocked package element was modified. So the warning it is not very helpful at all.
Can this be implemented so that the warning is actionable.
2 votes
- Don't see your idea?