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.
351 results found
-
Select the fields to deploy during a data deployment
Hi we use the data deployment feature is it possible to only select some fields to deploy data from one org to another and not always all the fields on an object.
19 votesYou can now select fields to exclude during a data deployment
-
Select individual fields in a Data deploy
Having the option to move up only selected fields in a Data deployment is needed. If we are required to move up all fields in each deployment, there are scenarios where our work will get bottlenecked in a sandbox on the way to production and at that point all the deployments will be identical.
4 votes -
Gearset silently removes SocialPost Layout Permission when deploying
When deploying from one org to a git repo (or other org) and selecting Layout + Profiles gearset will display a Layout Permission for the "SocialPost" object. However when completing the deployment "SocialPost Layout Permission" is removed because deploying it would cause Salesforce validation errors. This is not displayed anywhere and always causes "SocialPost Layout Permission" to show as "New" when doing a comparison.
2 votesThis behaviour was converted to a problem analyzer as of July 23rd 2021.
You should now be able to include these Layout Permissions in your deployment by ignoring the suggestions from the "Items that can't be deployed through the Salesforce metadata API" analyzer
-
Restore specific Salesforce files from backup
From the user interface, allow a backup user to select and restore a specific file from a backup job.
1 voteYou can now do this via the backup restore process - see https://docs.gearset.com/en/articles/6909509-deploying-contentdocument-contentversion-files-with-gearset
-
Refresh specific item in comparison through context menu
It would be great to refresh a specific item within a comparison that I know has changed since the last comparison.
107 votesGearset now supports:
- Refreshing a single item - available either from the context menu (by right-clicking an item in the comparison results table) or by using the "Refresh item" button in the XML preview window
- Refreshing selected items - available from the context menu once one or more items are selected
Thank you for commenting on and upvoting this request. We hope this new Gearset feature is going to speed up your workflow!
If anyone has feedback or suggestions, please contact us via the in-app widget.
-
Desktop notification when deployment is complete
When you launch a deployment to a target org the browser tab (which will be one of many in your browser) shows Depl...
Since the user is multi-tasking, it would be helpful to add a desktop notification and change the browser tab to alert user when deployment is done (like what Gearset does when a comparison is completed)
This could be a D ✅ or D ❌ depending on whether deploy succeeded or failed
2 votesThis has now been released, with notifications for both failed and successful deployments.
Thanks for the suggestion! -
Reuse earlier retrieved metadata, if nothing has changed
We have a large org and need to select many filters. A comparison take ages. Source of our deployments is mostly Git, which is very fast in retrieving metadata. I would like to have an option, to assume that nothing has changed in target and skip loading metadata of that org and use the metadata of an earlier comparison.
If we have a small bug in our Git (e.g, test class not correct), we get an error while deployment. That's okay. We fix it in about 1min and want to deploy again. Loading metadata from Git is instant finished loading…1 voteWe've recently made lots of improvements to comparisons which will improve performance. You can learn more in this video.
-
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?
-
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
-
Make fail job optional for warning PMD analyses
As a developer leader, I don't want the job to fail if I get a warning from PMD. But I want to be notified if the code has any warning.
I would like the failure for warnings to be optional. But always be warned that it has flaws.1 voteThis is released as of now.
-
Add ability to Ignore Warnings to avoid treating Salesforce warnings as errors
See IgnoreWarnings parameter: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy.htm
6 votesWe have implemented this feature now. To toggle the setting, navigate to My Account (using the dropdown next to the Gearset logo), then Salesforce deployment.
-
Option to group and show all selected items while creating new custom filters
Option to group and show all selected items while creating new custom filters
5 votesFilters > Selected Only option was release in the custom metadata filter on the 27 Oct 2020
-
Prevent Deployments from Including LiveChatButton with Omni-Channel Routing
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_livechatbutton.htm
LiveChatButton metadata that is routed using OmniChannel is not supported with the Metadata API and the deployment will fail.
It would be great if Gearset had an analyzer to remove this for end-users to prevent the error.
The following property is null for LiveChatButtons routed through Omni-Channel
<routingType xsi:nil="true" />
1 voteWe have now released the problem analyser requested – thanks for the suggestion.
-
Restore/export certain fields on objects
We (the user) would like to be able to restore data, but only select certain fields to be restored.
Usecase:
A business user triggers some automation that modifies a field or specific fields on a large number of records that should not have been modified. In the meantime, other fields may have been modified that were correctly modified. We would want to restore a set of records from a specific backup, but only the specific fields that should not have been modified.5 votesYou can now select which fields you would like to restore, via the "Restore changed fields within <object name>". Example in the attached image.
-
Search option when selecting a Data template
When choosing a template in a Data deployment, an option to search all templates is needed. We will be updating/modifying/saving new templates often and a manual scroll will become inconvenient. Control F works to find a template, but a dedicated search option would be preferable
1 vote -
Bitbucket pull request add Default Reviewers
When using the "Create Pull Request" link on the deployment screen, please add the "Default Reviewers" to the BitBucket pull request.
Currently we have to edit each pull request and add the reviewers manually.
5 votesThis has been released on October 1st 2021
-
Allow renaming of data deployment templates.
It would be very useful to be able to see the details behind data deployment templates and manage / rename them
1 voteThank you for your suggestion, Joost. You can rename a template that you’ve created by clicking the cog icon next to the templates drop-down on the Configure data deployment page, as described at the end of this doc: https://docs.gearset.com/en/articles/2529785-using-data-deployment-templates-for-repeatable-data-deployments
If you have any questions please let us know!
-
Default option for the deployment component list for JIRA issues
I really like the feature to add a deployment component list to a JIRA ticket. I would like to have the ability to default this ON.
It is currently defaulted to OFF.1 voteWe’ve made this stick to the last deployment on the release of March 19th, 2021. This is per team basis.
-
CI Job notification email should report the actual errors directly instead of linking to CI Dashboard.
This potentially can help the team to collaborate on the errors directly on Teams messages.
For example, at present, the MS team notification says [A continuous integration validation job failed for validation job for PR # xx], but doesn't say which CI job name or what the validation/deployment error was.
1 voteCompleted on 11/03/2021
-
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?