It would be very useful to have a Global Search feature within Gearset. This would be used to search the contents of all metadata objects.

My use case is that sometimes a string has been hardcoded inside a function. The only way to find the function that contains the string is to manually trace through the code. The global search would indicate the function that contains this string.

Another benefit would be to track dependencies for metadata objects that don't support dependency tracking. For example Aura Components, we could search for the component name.

Sometimes there is a difference between a object because the order of the platformActionListItems are different. Sometimes an item with order 0 comes first, but it is possible that an item with 9 comes first. This is probably an error in Salesforce API, but Gearset should order this list before the comparison so 0 will always be the first item.

In cases where you have multiple environments, provide an option to define a migration/deployment path; ability to define what environment is the source and what is the target. This will be useful in cases where we have requirement to deploy changes to say production from a specific environment (UAT).

In a CI job : Validation shown as success & Deployment shown as success. But actually no workflow deployed due to it being removed in the Problem Analyser.

The Problem Analyser triggered due to the (standard) object, that the workflow depends on, not being in the comparison results.

In a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap - problem analysers should never fire on object dependency.

CI job : Validation shown as success & Deployment shown as success.. but actually no WF deployed. Saying Opportunity object doesn't exist in target just because it was not selected in the components. in a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap.

When creating a new scratch org from either the Gearset UX or via a CI job, one often gets the Unknown Error message

Gearset should attempt to retry this error as often, a simple retry works. This is especially important for CI jobs which should not have to be attended to manually.

Of course, the better solution is to not get this error at all

If a CI job creates a scratch org ; and you configure an outgoing webhook in the CI configuration, the subscribers to that webhook have no way of being able to connect/authenticate to that scratch org.

The typical use case would be to run automated UX testing (Provar, Selenium)

At present, even the CI job creator can't log into the CI-created scratch org let alone any CI webhook

In addition to supporting this, there should be doc on how a downstream webhook can access the scratch org to then do useful work.

For org monitoring, we can get a notification on either every run, or when the org changes.

Could we also have the option to get notification when the number of static analysis problems increases?

Could we link the file names in the static analysis results to the actual code from the comparison/monitoring job?

i.e. Where the results have a list of issues per Apex class, I'd like the class name to be a link to the code for that class

Having a quick peek at the code from within Gearset can help me to diagnose whether it's a genuine problem, or something where the static analysis rules need tweaking.

If it's just the rules that need tweaking, it would be nice to be able to complete that job entirely within Gearset.

We have some custom objects that hold financial data so masking currency and Percent fields will help when doing data deployments

if path contains "./force-app" a bug appears, if we write "force-app" it works. so first one should work to

Repro step :

{

"packageDirectories": [{

    "path": "./force-app",

    "default": true

}],

"namespace": "",

&quot;sfdcLoginUrl&quot;: &quot;<a rel="nofollow noreferrer" href="https://test.salesforce.com&quot;">https://test.salesforce.com&quot;</a>,

&quot;sourceApiVersion&quot;: &quot;48.0&quot;

}

Result :
Comparision failed

Expected Result:
Comparision Ok

When retrieving metadata from 1GP packaging orgs, the <deprecated> tag appears in the source and, if you deploy to VCS, is preserved. But if you subsequently deploy to a scratch org, and back to VCS, the deprecated tag no longer appears in the scratch org and thus shows up as a diff in the Difference Viewer - confusing the user.

Doc says this tag is reserved for future use and until such time as it is used, suppress

Currently the Jira Ticket Deployment Preferences don't give you enough options to manage the expected behavior with our process. Right now there is too much noise on our tickets and we want the option to reduce that. For example, we do not need to comment on the ticket when attempting to validate deployment, just as we don't need it for failed deployments (which you already have as a feature). We simply want a comment with the deployment notes when a deployment is made since this would reflect the actual system changes that took place with this feature/issue.

When we validate a deployment then schedule it for deployment. Once deployed we receive a report however the tests run do not show here and you have to back to the validated section to find them - please include the tests run on the final deployment report

Ability to build sequence of data load (choose a list of data load templates and have to possibility to run them automatically in sequence). The sequence can be changed.

if the target flow is deactivated; and all prior versions are deleted, you can't delete the last remaining flow version in the target org. The error you get is "Insufficient access rights on cross-reference id".

Copado provides a solution (https://docs.copado.com/article/8l069zes9f-destructive-changes-in-copado-doesn-t-support-flow-and-process-builder) wherein the user can specify the contents of the destructive-changes.xml file (enumerating the versions to delete) but Gearset has no way to inject such a file into a compare/deploy (esp a CI deploy)

with SFDC pushing more and more dev into Lightning Flow, deletions are inevitable in many orgs as things get refactored/renamed

It would be super convenient to log into the scratch org directly from the Deployment success page

• From Compare & Deploy sequence


• From CI success

UX suggestion (tie list of scratch orgs to URL)

If you use Gearset to create a scratch org, the list of scratch orgs on the My Connections page does not tie to the visible URL of the scratch org you log into

This gets to be a real issue for the multi-tasker who might have several scratch org tabs open at once but has no way of knowing which one is which vis-a-vis the Gearset enumeration of how the scratch org was logged into the first place. Drilling into the user's name is too clunky