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.
1469 results found
-
Rolling back deployment made by CI JOB
Currently it is possible to roll back a deployment made by CI Job, though that rollback will only be performed to the specified Org. Hence, other Orgs have to be rolled back individually.
Use case: I have propagated changed from my Sandbox to Staging. An issue was identified that requires a substantial amount of work where that feature cannot be included in the next deployment to production, hence it needs to be removed from Staging. Though, other sandboxes back propagated that feature because they assumed it should work.
It would be amazing if the rollback used Github commits, so the…
1 vote -
Remove/Deactivate new feature for batch comparison
A few weeks ago, Gearset added a new feature to officially make the comparison faster, by showing already results of first batch and add the rest later on.
This feature makes it much more difficult to do comparisons. First of all, I don't see any benefit. I still need to wait for the whole comparison to finish, because I still need to now, what has changed. Why should I look into the first things, when I need to look into it again, after the rest is compared. So before I can select anything, I need to wait the whole time…
1 vote -
Add More Granular Control over Email Notifications
Allow users to enable/disable categories of email notifications at the user level. E.g. success emails for monitoring jobs, deploy succeeded/failed emails, etc.
Alternatively, or possibly in addition, allow users to "mass-edit" job notification settings, so we don't have to edit each one individually.
1 vote -
UI Change: On any pop-up page using Source Control, auto-expand to show Create Branch button
On a monitor job (and probably elsewhere), clicking "Deploy To" and then selecting Version Control target, you get a default branch, typically master. If you click the link to Create a new Branch from Master - you input the name of your new branch, but the Create Branch button is hidden below the display and you need to scroll down to show it. The Start Comparison button is where the Create Branch button should be, so you end up starting your comparison instead of creating the branch first. Suggesting to change the pop-out window to expand to show both buttons…
1 vote -
Archiving and restore process
Data archiving for storing records that can be easily accessed when marked as archived at an off-premise location. A backup and restore would be overkill when there is a need to store only partial records or a combination of fields from records in different objects. Restoring to a new object that does not interfere with existing objects would be ideal.
2 votes -
Enforce each deployment to have a Jira issue in a specific status in order to be able to deploy.
As a gate-keep; to be able to deploy anything to production (or any other named environment), the associated Jira ticket must be in a pre-select status.
For example, the Jira ticket's status must be in "Ready for Deployment" to allow an end-user to deploy.
3 votes -
Unify the message when you authenticate an org with a username that has been shared. It uses the term "delegated" instead of "shared"
Unify the message when you authenticate an org with a username that has been shared. It uses the term "delegated" instead of "shared". This could be confusing.
1 vote -
change monitoring for scratch orgs
The Change Monitoring feature only supports normal orgs (sandbox, developer, prod). It does not support scratch orgs
For use cases where developers inadvertently let their scratch org expire with pending, uncommitted work, it would be nice to recover the work before and after the scratch org expires
2 votes -
View on GitHub for custom git repository
Offer the option to "View on GitHub" for custom git repositories in Commit successful screen
1 vote -
Sort Validation Only CI Jobs
In the CI Job page, you can sort the top-level jobs by different columns (Job Name, Source, Target, etc...) but you can't sort the actual instances of that job.
We can get up to 30 PRs that are all being validated, and it would be nice to be able to sort them in some controllable way. It seems to rearrange them in whatever way it feels.1 vote -
Be Able to deploy Portal Sharing Settings and Organisation Wider Default Sharing Settings at the same time
For example if attempting to deploy
OWD permission Read -> Private, and Portal Sharing Set None -> Read. Gearset will fail validation due to SF complaining that Portal Sharing Settings cannot grant Read permission, since OWD is already giving that access.
Though what SF sees is that Portal Sharing Set is trying to give Read when it already has that access.Therefore, if I want to make the deployment then I would have to do in 2 steps.
1 vote -
Allow Data Deployment to handle more complex structures
Currently, user is able to select Obj A, Obj B that references Obj A, Obj C that references Obj B. And, in the next step of data deployment it allows user to select Objects where Obj A, B or C, and objects references by those objects.
If we ignore above example, I want to be able to select: objA(id), objB(id, objA), objC(id, objB, objD), objD(Id), objE(Id, objD). Where the first object I select and everything else is filtered on is objA.
1 vote -
Activity Task Event field level security validation in Profile
Hi Gearset Team,
I would like to have a metadata validation for profile field level security involving Activity, Task, Event object as they are related to each other in Salesforce.
For example:
If we do a retrieve for Activity, Task, Event object along with profile. In the profile metadata it would specify this:
<fieldPermissions>
<editable>true</editable>
<field>Task.FieldX__c</field>
<readable>true</readable>
</fieldPermissions>However, if there were to be a mistake in the profile metadata and we commit them in version control it is detected as a 'new item' in Compare and Deploy
<fieldPermissions>
<editable>true</editable>
<field>Activity.FieldX__c</field>
<readable>true</readable>
</fieldPermissions>When we select this new changes and…
1 vote -
Ignore Business Owner changes between Sandboxes
This was marked as "Completed" in https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/39507649-resolve-data-owner-user-metadata-from-difference
But really the issue remains.
When "Business owner" is populated in a field, it will show as "different" since the XML is showing username, which is different between sandboxes.
This make trying to do comparisons to find differences very challenging.
3 votes -
comparison between 3 or more ORGs
i would like to see in a future update about comparing 3 or more Orgs to possibly fine tune checks between production, and multiple sandboxes to make sure everything looks as needed to verify no sandboxes are overlooked for refreshes if needed.
3 votes -
Data deployments should ask if you want to Insert or Update or Insert & Update data
Data deployments should ask if you want to Insert or Update or Insert & Update data.
Currently it always performs data upsert only
2 votes -
Allow owners to setup delegated org access of members
Without already having delegated access granted there is no way to rollback a deployment from another user. There should be a permission to override this.
2 votes -
Exclude OmniStudio generated LWCs for CI
Currently OmniStudio will generate LWCs for it's flexicards and OmniScripts.
We want to have CI syncing in to a repository, however we don't want to have these autogenerated LWCs in the repository. This is code that users won't be modifying themselves, isn't constructed to be read by a human, and will actually be controlled by the Vlocity elements that GearSet already supports.
Reviewing the metadata produced by omnistudio, it seems that all the LWCs produced have the runtimeNamespace tag in their meta.xml file set to 'omnistudio'. It would be ideal if we could filter out all LWCs with that tag/value…
2 votes -
Expose Salesforce Validation Errors within Github PR
Currently when a PR Validation fails (Deploy CI Job with Validate Target setting turned on), the user can click the Gearset "Details" link to go into Gearset to see the exact error.
Many of our devs use VS Code and Github for their daily work and only rely on Gearset for the CI job. Having them jump into Gearset just to see the error is time consuming and not very intuitive for them. Sure we can find the same errors within the target org of the CI, but at that point the list of validations is large and it's hard…
10 votes -
Provide a better error when "invalid or null picklist values" is thrown.
"invalid or null picklist values" is thrown and i have too many picklists to figure out which one is the issue. Please provide speicific fields that are causing errors.
1 vote
- Don't see your idea?