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.
337 results found
-
Rerun Github validation on a PR without a new commit
When a CI job is set to run on a PR creation, if the source destination is missing something that the deploy requires, it will fail. To solve this, we must go to the source destination, make settings changes, and then make an empty commit to the pull request to re-run the CI.
It would be nice for there to be a link or button in Gearset to rerun the CI and update the Pull Request that the validation was successful.
2 votesIn the ‘continuous integration dashboard’ in Gearset, for ‘validate pull request’ jobs, there is a ‘run now’ play button to run the job manually. You can therefore update the target and then re-run the PR validation without needing an additional commit.
To be able to run the ‘validate pull request’ job manually, you need to have permission to run the parent CI job manually (e.g. be the job owner).
-
Require Jira Ticket Before Validation or Deployment
We would like the ability to make the "Jira updates" section required (i.e. ticket selected) prior to validation or deployment.
2 votesYou can now require team members to link a Jira ticket before manual deployments and validations.
Simply, navigate to My Account -> Deployment Settings and enable the 'Require Jira Tickets' option.
-
Include a Comparison for a Permission Set Group's Muting Permission Set
Include a Comparison for a Permission Set Group's Muting Permission Set. Currently, you can deploy a Permission Set and/or a Permission Set Group. However, if that Permission Set Group contains a muting permission set, Gearset doesn't pull the data. Here is a link to the SF guide on the muting permission set: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_mutingpermissionset.htm?search_text=muting%20permission%20sets
1 voteWe have now added support for this metadata type.
-
More granular control over CI job schedules
Currently, a CI job that deploys from a Salesforce Org to another org or source control can only be scheduled to run at 4 hours intervals. Additionally, there is no mechanism of specifying when these jobs will run - instead, the job is scheduled randomly within the first 4 hours it was created and every 4 hours after that point.
Providing a smaller interval (ex. every 1hr) and/or more granular control over the job execution time seems like a common sense enhancement.
14 votesYou can now set the interval to every 1 or 2 hours. Can you see is this matches your request?
-
Add a way to "Save" or "Save As" updated filters when in the Refresh Comparison window (like you can in the Compare and Deploy window)
When in the Refresh Comparison window, it seems there's no way to "Save" or "Save As" the updated filters. Looks like you can only access that feature via Manage Custom Filters from the Compare and Deploy screen
Any chance we could get that added? It would be super useful!
5 votesReleased on February 22nd, 2021
-
4 votes
When creating an account, a user can now choose to create a Gearset team that has data and metadata stored in the Australia.
-
Enable Gearset login from corporate SSO solution
an additional layer of security and convenience would be to enable Gearset login (that is, login to Gearset) to be done from an enterprise's SSO solution. We use Duo but Okta and others should be supported.
Just like we can login to Salesforce from our enterprise's SSO , we should be able to login to related apps in our suite of enterprise tools via SSO
6 votesWe support SAML Single sign-on in our Deployment Enterprise plan.
-
Ability to create Pull Requests for AWS CodeCommit
Gearset can create Pull Requests for many of the source control systems that it integrates with, but not AWS CodeCommit.
As AWS users, it would be very useful to use to have this ability so that we didn't need to switch systems to create Pull Requests.
3 votesThis functionality was implemented in February 2022.
-
Functionality to Data Deploy Active Orders
Salesforce doesn't support the creation or update or standard Order records with a Status Category of Active. This means Gearset is unable to data deploy any active orders. It would be very useful if there was an option for Gearset to temporarily set active orders to a draft status for the deployment or the Order Records and related Order Records, and then set the status back to Active for the final step.
4 votesYou are now able to dow this with Gearset Data deploys
-
Cancel a running data deployment
Currently I am trying to copy data from production into a sandbox and mask them, but I forgot to adjust the amount of records to create. Now Gearset tries to create thousands of records for each and also mask them with a lot of fields included. I would like to abort the process but don't see any option because this huge amount of data and background services consumes a lot of time and compute resources. Also, I can’t estimate how much time is still left to complete the data deployment. Also, just to see is also a huge improvement but…
2 votesAdded on the 5th of October 2020.
-
Add support for Currency and Percent fields to be masked during a data deployment
We have some custom objects that hold financial data so masking currency and Percent fields will help when doing data deployments
1 vote -
Support flow deletion at V44+
if the target flow is deactivated; and all prior versions are deleted, you can't delete the last remaining flow version in the target org. The error you get is "Insufficient access rights on cross-reference id".
Copado provides a solution (https://docs.copado.com/article/8l069zes9f-destructive-changes-in-copado-doesn-t-support-flow-and-process-builder) wherein the user can specify the contents of the destructive-changes.xml file (enumerating the versions to delete) but Gearset has no way to inject such a file into a compare/deploy (esp a CI deploy)
with SFDC pushing more and more dev into Lightning Flow, deletions are inevitable in many orgs as things get refactored/renamed
2 votesWe have added a problem analyzer that will detect when you are deleting a flow, and update the destructive changes xml to include all the versions automatically.
Thanks for the suggestion!
-
Add friendly Name to Deployment detail and be able to add/edit from that page
It'd be great to see the "Friendly Name" in the Deployment Summary page.
e.g. https://app.gearset.com/finished?deploymentId=XXXXXXXXX
And to be able to add/edit the Friendly Name on that page, same as it can be done in the Deployment Summary.
Our use case: We audit all our deployments to make sure they have a name. It would be very helpful to be able to send a Deployment Summary link to a user to tell him to add a name if it's missing.
5 votes -
Remove botUser from Einstein Bot metadata
The metadata for EInstein Bots includes a tag called "botUser" that contains the username of the user you've specified to run the bot as. Because it contains a username, the deployment fails unless you have the exact same username in both environments.
My current workaround is to deactivate the bot, remove the running user (which removes the botUser tag), deploy, then reset the changes that I made.
Can we get a problem analyser that will detect and remove this botUser tag so that the deployment will complete?
1 voteHi. We have implemented a PA for this now, which will remove the BotUser field if needed to prevent Gearset from trying to overwrite the user with one from the source.
-
Allow CI to do a quick deploy
Allow gearset CI to do a quick deploy either by default or via a setting on the Job definition.
Our tests run for nearly 90 minutes and are currently run twice in succession causing a lot of frustration. Once when a PR is validated and then when it is merged and deployed.19 votesThis functionality is now enabled automatically for CI jobs with the "validate pull requests targeting the branch" feature. This means Gearset will automatically try to quick deploy the package after the PR is merged meaning that tests don't need to be re-run. There is no need for users to change behavior and CI jobs will run and look as normal
-
To make it possible to abort started CI job on Continuous integration dashboard.
At the moment, you need to wait until the comparison is finished and the deployment has been started and then you should go to the org to cancel running deployment. It would be useful to have an option to abort the CI job.
11 votesThis feature is now available with the latest release.
-
Unique filename of the generated report PDF
Currently, the name of the generated PDF file of the deployment report is always the same for a given source and target.
If we deploy from our "master" gitlab branch to our "production" environment, the name will always be the same.
We archive the report PDFs for documentation / compliance reasons, and we always have to manually rename the PDF file to make the name distinct.
It would be nice if the name of the report PDF was unique. This could be achieved by either including a timestamp or the deployment number into the filename.
1 vote -
Update package.xml with destructive changes which helps CI jobs
When I commit components to bitbucket brach if I have 5 new components and 5 deleted components. then Gearset is updating package.xml in the src folder with only 5 components which are to be created but destructive changes are tracked no where. Then if we deploy from this branch changes to Sandbox using CI job which has 'Filter metadata changes using package.xml' checked, then the deleted components will not be deployed. It is good if Gearset give a feature to track destructive changes and deploy using CI job.
1 voteCompleted on October 29th, 2020
-
Deploy CMS/CRM Connection and and CMS Collections
We would like to be able to deploy CMS/CRM Connection and and CMS Collections. They are a part of Community Workspace.
1 vote -
Ability for team members to manually run the CI
Currently, only the owner of the CI job can manually run the CI. If the owner is out or unavailable, this creates a problem for team members because they have to deactivate the current job, clone and setup the new CI OR transfer ownership. Transferring ownership doesn't work if a team member is out unexpectedly, ill or doesn't have access to perform the transfer.
It would be helpful if you could grant access to a group of team members who have access to manually run the CI. This would save a lot of time and prevent having to keep multiple…
14 votesWe have made changes to the app on the 29th of June release for Enterprise licensed Gearset users:
Added the ability to run CI jobs belonging to other users if the source is a git repo and the target has deployment access delegated.
We think this now covers the cases:
- Allow an enterprise licensed user to run other people’s org to org CI jobs
- Allow an enterprise licensed user to run other people’s git to org CI jobsWe have not implemented allowing user to run other people’s org to git CI jobs. As this is sub use case is quite a specific interpretation of the original suggestion. Perfectly happy for it to be specified in another separate suggestion.
We have updated the documentation to reflect this change – https://docs.gearset.com/en/articles/2533179-access-levels-in-gearset
I hope this delivers the what your team needs. Feedback always welcome :)
- Don't see your idea?