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.
1301 results found
-
Add Salesforce Data Cloud sandboxes as an option for deployments
Salesforce Data Cloud sandboxes are now generally available but to promote changes from sandbox to production, the only options are through Data Kit and change sets, CLI, or DevOps Center. Having the option to use GearSet would be helpful so all deployments were managed the same.
3 votes -
Automatic sandbox updates option
The new sandbox updates process is really convenient - you can see all the updates a sandbox needs and apply one or more. However it is still very much a manual process to start it. We have a team of engineers and each one of them has to constantly go and trigger the update process manually whenever an update becomes available.
It would be really nice if there was a switch for 'Automatic updates' i.e. whenever it is turned on, the updates are applied automatically during off hours.
Of course if an update fails the engineer would receive an email…
3 votesThis is currently planned for later this quarter and next.
Users will have the option to:
- Bulk update selected dev sandboxes
- Automate developer sandbox updates; they will be immediately tried as and when ready
If users want to automate dev sandbox sychronization now, they can use CI jobs to deploy changes from their desired source of truth - this comes with some risk of affecting work in progress though.
-
enable using a Repository Access Token instead of a Service Account
I would like to be able to use a repository access token instead of a service account to connect to VC (Bitbucket in my case). https://support.atlassian.com/bitbucket-cloud/docs/repository-access-tokens/
The main benefit for me would be the ability to conveniently authenticate while maintaining a high level of security, even in situations where corporate change management policies and SSO requirements can be cumbersome.
3 votes -
Mask data that already exists in an environment
At the moment, we know that you can mask data whilst seeding it into an environment. However, what we would like a way to mask data that already exists in an environment.
A use case is that we have a full sandbox that contains customer data that we want to mask without needing to seed the data in first.
It's a common use case for organisations that deal with 3rd party suppliers but do not want their customer data exposed to the 3rd parties. For instance, a Salesforce implementation partner is delivering a project. They need access to the environments to build and…
3 votes -
Allow configurable default settings for Jira integration
Allow us to customize the default behavior for the Gearset<>Jira integration. Currently, Gearset posts a comment on the linked Jira ticket every time a commit is started and completed. This creates a lot of noise on the ticket.
Currently the only way to customize the messages posted to Jira are on a ticket-by-ticket basis. Allowing an option to customize this at the org/pipeline level (e.g. only post a comment when a deployment succeeds) would be very helpful.
3 votes -
Precision Deployments for Lightning Web Components
It is very much required to have Precision Deployment for LWC components as it is common to have multiple developers working on same LWC
3 votes -
Compare Types on Comparison
For the pipelines observed when creating a feature branch and during comparison runs, a default filter is applied to the compared types without any metadata types selected (0). We would like to have a custom filter with metadata types for a specific pipeline pre-selected by default when the feature branch initiates the comparison.
3 votes -
In a data deploy, allow filtering data by previously deployed parent objects.
For example, instead of "Only deploy Opportunity records that are children of the Account.Opportunities records that are being deployed" which filters opportunities by the accounts in the same deploy. You would have two deploys. The first would deploy accounts. The second would filter opportunities by those accounts already in the target org.
This would allow you to modularize deploys. You might want to mix and match subsets of data for specific projects. It would allow working around some of the shortcomings of the account hierarchy gearset magic. If there were transient errors (like exclusive locks) you could repeat a smaller…
3 votes -
Increase API call limits
There currently is a API limit of only 10 calls per hour for the reporting and audit API's. This makes it difficult when developing and testing applications that tie into the api. In our case we use the api to pipe the data into our observability platform for reporting and dashboarding. It would be nice to either increase to something not THAT low or to have a development override option of some sort that customers to request to temporary increase. I understand the need for some limits due to having a shared cloud platform but this seems to be on…
3 votes -
Grouping developer sandboxes in Pipelines - back-promotion to a group
Team,
Currently Gearset Pipelines only offers the option to connect a developer sandbox group to a single downstream environment. While back-promotion to a group isn't available yetCould you please enable it ?
3 votes -
Bulk resolve merge conflicts
We occasionally run into a situation where there are quite a few files with conflicts to resolve. We almost always are just wanting to accept all changes from the feature (not the environment). This takes an excessive amount of time through the Gearset UI to accept changes in every file. Would it be possible to add a button accepting all changes from feature across the entire PR?
3 votes -
Improve audit API to extract list of users and their entitlements. Additionally, allowing us to provision & deprovision user access via API
We use 3rd party tools to audit all of our user access at our company. Automating this via API instead of exporting CSV and loading that into another tool would be very beneficial. Additionally, we use that tool for provisioning and deprovisioning so if an API for that existed too, we could automate Gearset users.
3 votes -
Bulk resolving merge conflicts across multiple PRs (set resolution as Feature or Environment)
It would be great if there was the capability to bulk-apply Feature or Environment when resolving merge conflicts across multiple PRs. I have a few dozens that all need to be set to the same option, and it would be useful to handle this quickly rather than click on each one individually.
3 votes -
Give CI/CD Users the option to use a shared webhook or a new one in BitBucket
Gearset recently updated its automated webhook setup for new CI/CD jobs to use a shared webhook. For my team, we have configured each webhook for validation jobs to only run on PR creation/update and deployments to only run on branch pushes. By forcing the new jobs to a single shared job, it causes PR merges to trigger validations alongside the deployment (Which is time-consuming and needless).
Also, as my team has many legacy webhooks for our existing jobs, when we add a new job it seems Gearset randomly assigns it to an existing webhook. For our recent deployment-only job, it…
3 votes -
Attach specific Tests to Feature Branch Manually
I would like to have the ability to force a features jobs to run specific test(s) from the CI screen.
So if GS fails to detect a test class (either by error or b/c its not named in the expected convention) OR would have failed to catch breaking changes elsewhere, we can avoid/prevent this attaching a set of test classes to that feature branches deployment configuration in GS.
3 votes -
Disable Pipeline Back-propagation for Static Environments
We would like to have the option to disable the back-propagation in the pipelines for static environments or have more options to control how the back-propagation should behave, like not running the PR validations for these types of Pull Requests.
When new changes reach the master branch, those changes should be pushed to the branch linked to a Salesforce environment. As it is today, the changes are back-propagated through new Pull Requests and because of the pipeline default config, the unit tests need to run which can block the sandboxes for some time depending on the complexity of the release…
3 votes -
Limit who can connect Production or Specific Orgs
Our users may have access to certain orgs to do manual changes (we are working on reducing, but will probably never get to 0). Ability for us to block who can connect production can enforce usage of pipelines and prevent users from connecting their own user where they would get deployment access.
3 votes -
Trigger Gitlab Pipeline Faster
When opening a MR in Gitlab, the Gearset pipeline queues the Validation very quickly. However, in Gitlab, there is no pending Pipeline until Salesforce starts the validation. Sometimes this can be a lengthy period of time with no visibility inside of Gitlab.
Would be nice to trigger that immediately so approvers can see that it is queued, not just no pipeline job has been executed yet.
3 votes -
Set Problem Analyzer to default with all rules disabled
Problem Analyzer rules are automatically enforced for CI Deployments which are misleading to end user as the default has ALL rules set to enabled. My recommendations is to have the default template have ALL rules set to disabled OR have clear communication in the CI Deployment feature to notify users that Problem Analyzer rules are enabled and may cause expected deployment behaviour/errors.
3 votes -
Share edit access to a CI job with another user
Currently, only the owner of a CI job is able to edit it. This is a risk, as the owner is not always available to troubleshoot CI issues. It would be helpful to be able to delegate edit access to other team members so that pipelines can be managed collaboratively.
3 votes
- Don't see your idea?