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.
1444 results found
-
Gitlab Self Managed Issues
We suspect that reading the 'weburl' response field for the specified branch from an API call to GET 'v4/projects/$projectid/repository/branches' might be causing a problem when using public Gitlab proxies.
We suggest implementing a code change to compare the domain of 'web_url' to the self-hosted GitLab domain provided by the customers. The customer's self-hosted GitLab domain should take precedence.
1 vote -
Set up notification according to the target connection we're deploying to.
Set up notification according to the target connection we're deploying to. This way, the scheduled and manual deploys will notify us with what we set up.
1 vote -
Soft delete User accounts
If you ever delete a user then that account can never be used again or added back. Rather than provide a warning with text that not everyone is going to read it would make more sense to not even have the delete option in the first place or do a soft delete where it can be reactivated. We have employees that have left the company and returned so its not an uncommon scenario. If someone leaves or an account gets deletes accidentally it would be nice to have some sort of recovery option then to not allow that email address…
2 votes -
Please adjust problem analyser feature to show record type changes when a picklist field value is added.
Currently Problem analyser does not show any warnings or issues when record types are not selected for a picklist field changes( value addition). With this during deployment there is fair amount of chance that some one could easily miss record type changes. Please adjust problem analyser to account this situation and show record type changes as warnings would be beneficial.
2 votes -
Allow deployment of 'Check For Matching Records' in Flows.
As part of the new Salesforce Summer ’24 release, Salesforce have added the ability to check for matching records when using a ‘Create Records’ element. We’ve used this useful feature in various locations within our new flows to identify existing contacts for example.
When deploying the flows using this feature between developer environments via Pipelines or Compare & Deploy in Gearset, we’ve noticed that this new setting within the element doesn’t get deployed and is switched off in the destination org.
In the meantime, we can manually turn on this feature in the destination org.
1 vote -
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?
4 votes -
Allow open PRs to queue up.
Allow open PRs to promote via selection and to queue up against the target keeping blocking behaviour to just merges and the deploy activity
1 vote -
Problem Analyzer should remove picklist values from record types when picklist values are removed from the picklist or value set.
When removing or deactivating a picklist value, Problem Analyzer should remove these values from any record types that reference them. While the initial deployment of the picklist may succeed, subsequent deployments of the referencing record types will fail if they still reference a deactivated picklist value.
1 vote -
Picklist Comparison should show if value is active/inactive
When comparing a picklist in which we have deactivated values, the simplified comparison visualization shows the deactivated values as being "added" (in green, on the source side).
The XML reveals <isactive>false</isactive> is being added, but the simplified view seems to suggest new values are added instead
1 vote -
New, one-click "Promote" button is very risky
In Deployment Pipelines when a PR for a CI Job is selected, a new, one-click "Promote" button exists, if the PR passes merge-conflict and validation checks. This new button is very risky in that it begins the promotion process, without recourse, when clicked.
Perhaps that's the designers intent but for myself at least, the button is too easy to accidentally click out of inattention, distraction or mouse clumsiness and is especially risky in that I cannot recall the action.
Personally I like the process of clicking the PR checkbox and clicking "Promote", which prevents unintended deployments.
As an alternative to…
1 vote -
Add pipeline support for CPQ
CPQ deploys to and from Github/Salesforce so it should be a relatively simple issue to include this in the pipeline deployments. You could add a checkbox or just warning to ensure that triggers are manually disabled when that is needed.
5 votes -
Configure the "Saved Comparison Pair" to always use a specific Comparison Filter
When managing multiple orgs, and running comparisons, the Saved Comparison Pair saves a lot of time. However, sometimes we need to use different Comparison Filters, based on which environments we are comparing.
Instead of first choosing the Comparison Pair, then manually selecting the Comparison Filter to use, it would be great to be able to (optionally) configure the Comparison Pair to use a specified Comparison Filter.
Example Use Case:
When committing work from our Dev org to BitBucket, we exclude Apex Classes & Triggers, and mainly commit declarative functionality (Apex code is committed separately from our dev team). All development…
4 votes -
audit report missing PR message
The audit reports don't include much context of the deployment, which means they are pretty useless to us and do not serve our auditors' needs. Specifically, they do not include the PR message for deployments through our pipeline, which means we can't link each deployment to the specific ticket responsible for that deployment. The PR message is where we put our ticket. This information is needed for our SOX audit process. Additionally, we can not see a link back to the deployment, which would allow us to quickly reference the specific metadata files/components that were deployed.
1 vote -
Pre-fill Pull Request Description with comments from last commits
In order to save time, when a Pull Request is created from the Pipeline, the Description field could be pre-filled with the comments from the last commits in the feature branch, instead of forcing the User to type something.
1 vote -
Use location of metadata in source branch or local folder when adding to target branch
When adding a file from a branch or local folder (source) to another branch (target) not having the file, use its location in the source as the location in the target.
Currently all new files are placed in the default folder [1].
Let's assume a new file, "HelloWorld.cls", in the source is located in .../force-app/main/default/classes/special/ and that class doesn't exist in the target. When the deployment is complete the file should exist in the target's .../force-app/main/default/classes/special/ folder, matching its location in the source. Currently it would be placed in .../force-app/main/default/classes/.
[1] https://docs.gearset.com/en/articles/2835001-structuring-your-source-control-repository
1 vote -
Save sort order of grids
It would be nice to be able to sort by column names and save that sort order for the next time the page loads or save a default sort order. We sort often by jobname and would like to not have to resort everytime we need to touch a ci job to sort the column.
1 vote -
Delete feature branches in Github in a way that they can be restored
I closed a PR to master, and Gearset deleted the feature branch. However, it wasn't merged, so I wanted to restore it to continue work. I was completely gone from Github. I believe Gearset should do a normal delete that allows restoration instead of completely obliterating feature branches or allow an option to do so.
6 votes -
Get Notified if Pull Requests or Validation Fails
Our Org has Gearset Officers who handle promotions. It happens at times that I create a pull request and have it start validating (which can take a while). I'll navigate away from the screen and totally forget about it, assuming it'll get pushed to the next environment.
But sometimes there are merge conflicts, or validation fails. I'd love to get a notification, either in email, or as an integration to an attached jira ticket that it failed. That way ill be notified by slack or whatever.
Just an addendum here. We use 3 environments. Admin, UAT, and finally Production. When…
7 votes -
Add support for OverrideSettings for Vlocity datapacks
It would be great if there is a way to set up OverrideSettings https://help.salesforce.com/s/articleView?id=sf.os_build_tool_override_datapack_settings.htm&type=5 for the deployment pipeline. For example, FilterFields can be specified, so those fields are removed from the datapack before being committed to the git repo.
This should help to reduce the number of differences in the compare view when e.g. Salesforce IDs are different or empty attributes are added.
2 votes -
is it possible to add a filter for "selected feature branches only" ?
is it possible to add a filter for "selected feature branches only" ? My business problem is that i am a deployment manager and i need to quickly validate what ive selected before building the release.
1 vote
- Don't see your idea?