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
-
re-add "re-authorize" link on compare view
After refreshing a sandbox, you have to re-authorize the sandbox-org. A while ago, there was a link to do so. Now we have to navigate to the list of orgs to re-authorize there.
Please give us back the re-authorize shortcut :)
4 votesWe have now added a 'Re-authorize' button to the access token expiry warning message that will typically appear when selecting Salesforce orgs with an expired token on the initial 'Compare and deploy' page.
-
Option to sort Custom Application XML
While this can be done with VSC custom plugins for SFDX, I think it would be really beneficial if Gearset offered the ability to sort Custom App XML in comparisons in order to see what's actually changing between a source and target for lightning page activations. Due to the way SFDC generates this XML, the way page activations are ordered is very difficult to follow, and I think it's an opportunity to make that easier especially for declarative config users of Salesforce.
5 votes -
Offer Canadian data residency.
We have clients in Canada that require data residency for data backups/deployments and even metadata deployments/processing.
Please add the option for a Canadian hosted Gearset account.
6 votesHi there,
We have now added Canada as a data storage location. You can head over to app.gearset.com - click on create new account and sign up for the same.
Thanks
Gearset team.
-
Allow users to specify when to apply Environment Variables
A good feature would be to have some setting that lets you declare when you should apply environment variables. Since right now it is applied automatically during manual deployments and CI deployments. Perhaps in the wizard when you configure deployments there should be some option there to declare if environment variables should be applied or not?
We have some Custom Metadata and Custom Settings that always need to be updated post-refresh based on the new sandbox instances and it would be useful to use environment variables to set these values and deploy them one-time without them being deployed in every…
2 votesEnvironment variables will only be applied if its configuration as specified by the user (metadata type, item name, and a field for some types) matches the type and item name in the deployment package.
In all other cases, environment variables won't apply.
Added clarification in the Environment Variables config page:
"Environment variables will be applied automatically during both manual deployments and continuous integration deployments if the metadata item is included in the deployment package."
-
add an option to sign commits with GPG key
If a source control space has enforced GPG key signature for all commits, gearset is not able to push any commits.
2 votesYou can now sign commits with GPG keys in Gearset. This article explains how to set up commit signing in Gearset. Commit signing is available on the Deployment Teams and Enterprise licenses.
Please let us know if you have any feedback via the in-app widget or by emailing team@gearset.com.
-
Add an option to ignore location changes for Flow
Hi, when reviewing changes for flows that are being deployed, it would be great to have a toggle option to hide or alternately color location changes which are just the location of elements on the flow canvas editor.
<locationX>1353</locationX>
<locationY>1305</locationY>Sometimes there are hundreds of location changes and it obscures the important information about what else changed.
21 votesThe "simply differences" toggle in the comparison grid now hides location changes in flows to make it easier to identify important changes. The location changes are still included when deploying changes to the flow.
-
Identify that metadata is the same, even if ordered differently by metadata API
There are a lot of instances where the comparison will identify metadata as different, but the only difference is the way the API is ordering the XML. I've seen it happen a lot with picklist values on multi-select picklist fields. It would be nice to be able to turn this on/off somehow so that metadata that isn't truly different won't show up in the difference compare.
13 votesPlease see if anything else could be improved on in the feature description released in Nov 2021.
-
Populate Pull Request Templates from git providers
When creating a pull request directly in Gearset, it would be ideal to pull in the existing templates defined in BitBucket or GitHub.
A middle of the road solution (if GiHub or BitBucket's API doesn't support this) could be defining a pull request template in Gearset.
2 votes -
Ability to activate / deactivate Flows / Processes as part of the meta data and/or data deployment process
It should be possible to have gearset to deactivate flows and/or processes based on a selection. And to roll-back afterwards. Similar to what has been created here: https://sfswitch.herokuapp.com/
10 votesHi, thank you for voting on this UserVoice.
Flows can now be deactivated in Gearset alongside validation rules and triggers before data deployments.
Click the View and disable rules... button in the bottom-right of the pre-deployment summary page (next to DEPLOY DATA) to prepare a special metadata comparison.
To deactivate a flow, simply select & deploy its corresponding flow definition.
https://docs.gearset.com/en/articles/4536761-disabling-validation-rules-triggers-and-flows
-
Clone CI job without delta enabled
As the Gearset administrator for my team I want to be able to clone a CI job that is set as a delta job without the delta flag enabled so that I have less effort to create a brand new CI job.
Acceptance criteria:
- When closing a CI job with the delta flag enabled, give the option for the new job to now have the delta flag enabled.
- If the source and target are the same as an existing job, provide a visual warning of the potential consequences of replication of the job.
1 voteHi, this feature has now been released.
When cloning a CI job with delta enabled, you should now be able to toggle the delta CI checkbox when configuring the cloned job -
Ability to Name a Backup Run
It would be great if you could name a backup run.
Sometimes when backing up its handy to label in in case it was done for example before a deployment or large data load. Then this can be identified in the future or to refer back to it. Otherwise you need to remember the date and times! :)
1 voteWe've added friendly names to data backup runs! 🎉
Please get in touch if there's any specific places you would like us to display this friendly name in place of timestamps.
-
Support org shape parameter for creating Scratch Orgs
Currently definition files are required for creating scratch orgs but there is no support in GearSet for the use of the sourceOrg parameter as per the sfdx documentation here : https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_scratch_def.htm
4 votesWe’ve now released support for the Org Shape feature which is available when creating a scratch org.
-
Show deployment friendly name on Deployment successful page
On the "Deployment successful" page, I'd like to see the Deployment friendly name displayed. This would be much more useful than the Salesforce Id that is currently displayed.
3 votesReleased this week
-
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! -
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?
- Don't see your idea?