Problem analyzer is always trying to remove my picklist values from any RecordTypes on PersonAccount. I am forced to use a custom "Problem analyzer template" where "Remove picklists from record type" is disabled.

Suppose I have a field called pickme: Account.Pickme--pc | Contact.Pickme--c it shows up in the record type XML as Pickme--c, and it seems like gearset tries to find a picklist on account with that exact API name, which will of course fail. My ask is that rather than raising an error at this point, GS should repeat this check on the contact object where it would find a match.

When setting up a deployment, it would be helpful to capture Deployment Results in a custom object in the running user's Salesforce org. Users would be able to specify a unique reference at the point of deployment, which would track through to the Salesforce org.

Information about the deployment would be captured in a Master record, with data about individual components existing in Detail records.

Org admins would then be free to leverage automation features to map the created records as they see fit.

As a consultancy that tracks our customer requirements in Salesforce, our use case would be that a 'requirement' record would become the source of truth for everything that happened with that requirement without manual intervention.

It would be great if we can have the option to set and make use of 'deployment rules':

1 - receive an alert/warning message (in gearset/via email) right before deploying to a selected target environment, for instance - a production environment if certain pre-defined metadata types are included in the deployment.

use cases: a reminder to run all test when deleting metadata, a reminder to activate a flow on target environment after deployment.

2 - block a deployment in the following case scenarions:

a - if the deployment of certain pre-defined metadata types happens within a pre-defined timeframe.

use case: deployment of sharing rules during business hours

b - if certain pre-defined metadata types are not deployed by a certain role (e.g. team lead/owner).

use case: only team lead can deploy metadata for critical components (e.g. account and case triggers).

Criterias that may be used:

• metadata types included in the package
• keywords
• users
• date/time range
• target environment

Expose the underlying JSON/XML for Custom Filters so that we can export it, modify it in a text editor either by hand or with python scripts, then load it back into the custom filter.

For example I have my main CI filter with 50ish metadata types, and every other filter is a subset which I establish by cloning the "master" filter and deselecting metadata types. Whenever I make a change to the master filter I am forced to nuke all the the "detail" filters and recreate them off the master using the above approach.

So many clicks. My preference would be to manage all this as text-based files.

Allow triggering Data deployments via the public API to eliminate having to sync data manually. This also includes triggering creation of Scratch Orgs via the Gearset API so that Gearset can instantly recognize them them.

The workflow we would like to automate is: feature branch is checked out which triggers a CI/CD system pipeline to create a corresponding scratch org, do a metadata deployment from a test sandbox, and sync data from the same test sandbox. This allows us to create on-demand full copies of the environment for purposes of E2E testing (inc. external integrations) and feature development that requires test data.

I would like to see support in the 'XML quote escaping style' for Illuminted Cloud (and potentially other IDE Vendors)
I am struggling currently as my Admins use gearset for source control commits and my developers use Webstorm and Illuminated Cloud which causes conflicts (generally with the utf/UTF issues but some others as well around validation rules and some formula fields).
Ideally, If a team standardizes around one IDE then all they have to do is come in to that setting and set it to what the IDE does as a default and then you wouldn't get any conflicts with the separate paths moving items to git.

When a PR in GitHub is being validated, Gearset doesn't let GitHub know that the check is happening until after it has run the comparison between GitHub and the target org. Then the check is pending while the validation runs in Salesforce.

This means that there is a delay between when you create a PR and Gearset's check appearing as pending in the PR. At that moment, it looks like there are no more checks to run in GitHub so you can go ahead and merge. But, you really should wait until Gearset has compared and validated the changes.

It would be clearer if Gearset notified GitHub that it was running a check immediately.