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.
1304 results found
-
Add "View Validation in Salesforce" to your Github and Teams/Slack Channel messages.
Our pipeline is utilized by some implementation partners that we do not give access to Gearset. They manage their changes that flow through the pipeline with GitHub and receive pipeline updates in a Teams channel. Both of these options have a message to view validation errors in Gearset but the partner teams cannot see Gearset. If these messages included the same "View Validation in Salesforce" option that lives in Gearset, they could be redirected to the Salesforce error page to help their troubleshooting faster.
10 votes -
allow configuration of problem analysers for different target locations
If we could turn of problem analysers for specific locations (e.g. Git repos) this would allow us to remove irrelevant problem solutions from our git commits, but keep them for deployments
1 vote -
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 -
distinguish between components of feature branch and what is syncing to main
As a user of gearset deploying pull requests to multiple environments
I want to be able to identify actual components of the feature branch vs. what is included for syncing to main/main branch for the org being deployed to
So that there isn't the confusion of understanding what new/changes items are showing up in the commit information1 vote -
Ability to automate deployment to a particular environment without manually promoting changes
When there are multiple Salesforce environments in the deployment pipeline, like Integration, Qa, Stage and Production, we would like to have ability to automate deployments to a specific environment, without having to select PR and promote changes manually. Most of the times SIT/Integration environment will be used for Developers to be able to perform integration testing, where we do not want someone like a Lead to review and promote PR manually. It will be beneficial to deploy the changes automatically, as soon as someone creates the PR to the Integration environment.
9 votes -
Create a link in the main menu under Data Deployments for managing Data Deployment Templates. It is not very intuitive to manage them curren
Create a link in the main menu under Data Deployments for managing Data Deployment Templates. Having to start a deployment in order to manage the templates is not very intuitive.
1 vote -
Automatically Defer Sharing Calculations
Salesforce has a feature to "Defer Sharing Calculations" ( https://help.salesforce.com/s/articleView?id=sf.security_sharing_defer_sharing_calculations.htm&type=5 )
It would be awesome if Gearset Pipelines could have an option to utilize this, if sharing rules are included in Deployment, defer sharing rules for any validation / deployment, re-enable and recalculate after deployment
1 vote -
Please add Namespace/Package name as a column in the comparison view
Currently , if I pull down metadata from managed packages (e.g. with the intention of committing the custom fields we've added to managed objects or committing the permissions we've updated) this means I get all the metadata in the comparison screen, with no way of filtering out the managed packages. An example of where this is a problem/cluttering the UI is Triggers/Classes - the contents of these is always hidden, so ideally i'd like to have a column to filter them out
1 vote -
automatic pipeline deployment on successful validation
For Pipeline jobs, provide an optional feature (ability to toggle on/off) where if an Open PR has successfully validated on the target org, then auto deploy to target org. This is useful when propagating changes in downstream jobs. For example, once code review is done, a PR is merged into DEV by pipeline admin, but it should also automatically be merged and deployed into QA if the validation is successful.
5 votes -
Ability to rerun deployments
We had a deployment in a pipeline that included a change in a managed package. the MR to the environment branch has the permission set change (access to a managed package field), but the Pipeline did not deploy it. It would be great if there was a way to "re-run" an already promoted branch, as we can't use a MR at this point to trigger, since the repository already has the change.
1 vote -
Provide deployment history by Salesforce ID or My Domain
If we could have a way to quickly export all changes to specific environments regardless of user who created the connection, would be ideal.
Use case: Provide a Production OrgID and be able to export all changes across all connections and manual compare-and-deploy and pipeline deployments.
1 vote -
Enforce Promotion Approval Rules
The current UI shows a green checkbox and allows you to attempt to promote changes between environments even if the merge request is unable to be approved. Looks like it in Gitlab there is an 'approved' attribute that may be able to be used.
Alternatively, can have some basic rules but would like it called out its not ready to Promote in the Gearset UI.
4 votes -
Ability to export deployed components for specified period of time
Instead of viewing it by deployment package, it would greatly help us to be able to export all components deployed during a specific period of time. It would help to include the following:
Deployment friendly name
Source
Target
Date and Time
Deployment Status
Owner
Metadata Type
Name
Difference Type2 votes -
Make the PR Title same as the validation friendly name and deployment friendly name
This helps us find the related validation and deployment to the CI job without having to open multiple validation/deployment records.
1 vote -
Allow Jira Ticket Association Changes on Commits
Please allow the Jira Ticket Associated with a Commit to be updated once the Commit is Successful. If a mistake was made prior to commit and the incorrect ticket was entered, there is not currently a way to change/adjust the associated ticket to the correct one.
1 vote -
Add navigation options to the data deployment process
We are making use of the data deployment tool to seed our sandboxes with test data. When you execute a template it always navigates you to the last step (which makes sense). There are times however that we need to go back to the 2nd step and change filter criteria. This includes several clicks and waiting for pages to load.
Is it possible to add a navigation bar at the top that shows the various steps so you can quickly jump to one you need to update?
ie Step 1 > Step 2 > Step 3 > etc1 vote -
Create releases in Pipelines not at final stage
Right now you can only create releases at the last environment in a Pipeline. We'd like to have 2 stages so we have a true dry-run of deployment. Our pipeline is
Dev > QA > UAT > Staging > ProductionCreation of the release branch before Staging would allow us to effectively cherry-pick what we want deployed into Staging as we get UAT approvals, do a test deployment where QA does a sanity/smoke test and have greater confidence when we get to our Production release.
11 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 -
Integrate with Salesforce's Setup Audit Trail for Metadata Detection
Many metadata types are referenced in Salesforce's Setup Audit Trail. An alternate way to detect changes to include could be querying Setup Audit Trail with a Start / End Date instead of asking user to select the necessary components.
1 vote -
Create a Combined view of Monitoring and Pipeline with Alerts
Monitoring is great, but doesn't have a correlation to Gearset deployments (direct or Pipeline).
A view of all changes to org and call-outs of which were Gearset-driven and which were manual would allow us to use Gearset more directly in SOX audits as proof of controls.
Giving us actionable items, whether its in Gearset UI or Source Control to document review and approval of manual changes would be a huge win.
1 vote
- Don't see your idea?