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.
1301 results found
-
Allow users set their own default tab view when viewing the comparison between orgs
The recent change (March '22) to change the default tab when viewing a comparison from Changed Items to 'All Items' makes it more difficult to quickly see changes, because maybe there aren't any. The All Items list would also be extremely long if the org is particularly complex.
As such, I propose that you give users the ability to select their own default tab when the comparison page loads, so we can choose to always view 'New' or 'Changed' items.4 votes -
Approval process for metadata deployment
It would be great to have a approval process for the deployment.
For example, once we have completed the comparison and validation, we can click a button "e.g.: Submit for Approval" and an email will be sent to a list of email.
In the email, receiver can review the summary of the deployment (e.g.: source org, target org, number of changed/new/deleted components, ...) and click on a link to approve or reject the deployment.
We can deploy only when the job is approved.5 votes -
BitBucket commit on a successful Org deployment
It would be a nice feature to have a setting on the deployment summary page to also commit to a git branch with deploying to an org.
2 votes -
Force-deploy Flow translations with no difference
At the root of this, the main problem is that if you create a new flow version through the SFDC flow editor interface, the flow will have a new version of the flow translations based on the previous translations.
But if you DEPLOY a flow, the new flow version is created WITHOUT flow translations at all.
This would be fine, if gearset would allow us to reliably deploy the flow WITH flow translations, even if the flow translations had "no changes". (Gearset does not allow us to deploy items with no change, and sometimes doesn't even show them in the…
2 votes -
Integrate with Rally as an option in addition to JIRA/ADO
We have customers who use Rally to manage their requirements similar to how many use Jira. Would be great to have this capability
1 vote -
Add Time Column to the CI Deployment page
Due to recent latency issues regarding SF performance issues, I would like to quickly see how long each CI job takes without having to download an individual report for each job. This can either be solved by either:
Adding a field to the CI Deployment page so that I can compare each CI job
Allow me to extract a complete report of all of the CI jobs and open it in excel with the time column so that I can compare the values. I can currently do this from the Deployment history page, however this does not include the CI…
2 votes -
Retrieve Metadata into local environment (e.g. using VSCode pluging)
This would make the integration of Version Control and Gearset nicer. Where now user has to go to Gearset deploy to a feature branch, afterwards, go to VSCode pull from the feature branch.
1 vote -
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 -
Support SAML-based SSO and SCIM-based user provisioning
To improve security, user experience and reduce user administration time, SAML-based SSO and SAML JIT provisioning or SCIM-based provisioning would be fantastic.
3 votes -
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 -
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
- Don't see your idea?