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.
1243 results found
-
Pull Request Branch Filter/restriction
Currently creating a pull request from the "Create pull request Screen" provides the user with a list of all the branches.
The default of this seems to be based on the last location you had selected when you created your branch (This usually ends up being main). As we have a pipeline this is the last place you want anyone being able to create a PR into!
It would be great if we could whitelist/blacklist a bunch of Branch names on this dropdown to stop users accidentally selecting main when creating a PR (for most users this would be one…
2 votes -
disable the ability to delete backups to prevent malicious actors and accidental damage
A lot of backup providers offer the ability to disable the ability to delete backups. This provides protection for 2 scenarios:
A hacker compromises an administrator account and uses this access to remove backups to prevent recovery after ransomware or other attack
An administrator accidentally deletes backups that are required
If there is a legitimate use case for backups to be deleted, the ability to delete can be temporarily turned on but only by contacting support and only with the confirmation of 2 or more admins.
2 votes -
Run pull request validation against a different sandbox than the one linked to the target org
Hi team,
We have multiple developers creating PRs against a common development branch (let's call it simple, develop; developers are creating their feature branches from master, the Production configuration branch). Develop branch is linked to an integration environment (called INT). INT environment contains multiple stories which are not yet in Production (some of them might go in Production, some will not go).
I would like to get my PRs validated in a Production-copy environment (called BUILDCHK) just to get a real feedback on how "deployable" are my changes in Production, for whenever their time will come.
It would be great…
2 votes -
Add the checks on the PR for the deployment
Currently, gearset doesn't provide the checks on the PR for the deployment CI job. It would be nice to have the checks of the deployment status along with a link to the comparison on the PR, similar to how we can link out to the validation job
2 votes -
Allow switching authentication provider (SSO)
I made the mistake of using the wrong SSO provider (Salesforce) on the main user account that owns all the pipelines, CI jobs, credentials, orgs, etc and now I'm stuck with it with no decent way of changing to Google, my preferred provider. Please create an easy way to switch SSO providers.
2 votes -
Include "Messages reported by Salesforce" during Metadata Deployment in the final report
During a metadata deployment, on the "deployment in progress" screen, there is a column for "message reported by salesforce".
I think these should be included in the final results screen, and perhaps in the deployment report.
These can be useful for the user to do things like make changes to their flows to conform to salesforce best practices.
2 votes -
Provide deployment options for Mulesoft via Gearset
As Gearset does Salesforce based deployments so well, it would be great to have Mule deployments done through Gearset as well.
2 votes -
Recognize code formatting changes as differences that can be deployed
If an Apex Class or other code file has been modified to fix formatting only, changing the indentation size for example, Gearset doesn't recognize this as a change that can be deployed. Formatting changes are recognized by git and SFs own source tracking feature so it should be recognized by Gearset.
2 votes -
Save Filtered Metadata from a Comparison View as a New Custom Filter
When running a compare, we'll often filter the list of metadata types in the results to eliminate types we're not interested in comparing. It would be nice to save the filtered view as a new Metadata Filter for use in a future compare.
2 votes -
Feature vs Release, Branch De-sync
When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.
Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.
Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the…
2 votes -
Allow a PR template from GitHub to pre-populate the PR description
There is a feature in GitHub to auto-populate the PR description (forcing, for example, a checklist if using the web UI). If Gearset could read that template and pre-populate the PR description so users have to put in specific comments (such as manual steps to be done after deployment) and if that description were exposed in GitHub, then it would be more seamless and the deployment history would enable an admin to work through each manual step without looking in closed PRs in Gearset.
2 votes -
Integrate with Linear
Linear is quickly becoming the new Jira for today's technology and engineering teams. It should be considered an important integration.
2 votes -
Link to the Salesforce Validation in Progress from the Pipeline
When I deploy using the standard deploy interface, there is a link that allows me to view the deploy progress in Salesforce.
In pipelines, I would like this same feature. When a deploy has been running for a while, it's useful to know where it is in the process and a quick link would be quite nice.
2 votes -
Provide and enforce branch naming conventions
Branches get all kinds of really stupid names over time. It would be nice if Gearset provided an option to template new branch names. For example when my users need to create a new feature branch for their user story, Gearset should prefix that branch with 'feature/'. When a release branch is created it should be prefixed as 'release/'. Bugfixes or Hotfixes could be bugfix/ or hotfix/.
Dictating naming conventions is unenforcable. Keeping branch names organized goes a long way to keeping the repository maintainable over long periods of time. Even if folks are well intentioned, git branches are case…
2 votes -
Allow Quick Deploy when merging multiple PRs using Pipelines
currently when merging multiple prs using pipelines the merged package validates and then the prs are merged, the resulting deployment then revalidates even though quick deploy is an option, can we use quick deploy when available like was enabled in the ci jobs?
this would save time by avoiding double validation and make the feature more usefull.
2 votes -
When Problem Analyzer adds Fields, Add Profile Permissions Too
Currently the problem analyzer will identify missing fields. However, it doesn't prompt or allow you to add the permissions for the fields. So, you either have to go back, manually add all fields as Selected, or push the package and then go back manually and add permissions for all fields. It should prompt to add both the fields and the permissions.
2 votes -
Filter on UNselected items when choosing metadata to compare
When selecting metadata to compare, there is a picklist that says "Filters" and has an option for "Selected Only." Please add a second option for "Unselected Only" so I can quickly verify that I haven't left anything out without my eyes being distracted by checkboxes and items I know I already selected.
2 votes -
Flexible Org Monitoring Notification Scheduling
I'd love to schedule a weekly or bi-monthly digest email rather than receiving emails for each run or each change. There are developers who need to know when changes are made, but they do not need to monitor changes frequently. In those scenarios, it would be nice to schedule out a weekly review of all changes.
2 votes -
Send Email when a package is Validated successfully with PDF of Deployment Summary.
We currently receive an email with deployment summary as PDF attachment after successful deployment, but we also want this feature for successful manual validation. This is help us review the validated package summary with Deployment approval teams in our ORG.
2 votes -
Only notify the Pull-request creator on validation errors
Hi team, not sure if there is a way to do that in the current setup, but I think it would be helpful to add the option to only notify the Pull-request creator/owner on the validation errors, instead of "hardcoding" the email recipients. Regards, Adrian
2 votes
- Don't see your idea?