It would be great to refresh a specific item within a comparison that I know has changed since the last comparison.

As of now we are able to send only static text as a part of outgoing payload in CI Integration jobs. We want this data to be dynamic for each deployment.
For example: We need to send the information like (JIRA User Story number, GIT commit hashes and descriptions from the pull requests being merged, etc.)
This will allow us to publish information of successful deployments to external system.

When entering test class names in the text field, invalid entries can be added without any indication that there is something wrong, which would lead to uncovered code and most likely a failed deployment. For example, entering in ThisIsAnInvalidTestName would not result in any error.

In the past in Gearset, you were able to see the status of your deployment (e.g. 100/200 test classes, etc.) very similar to how you would see the native status tracker on the Deployment Status page within Salesforce Setup. It appears this feature is no longer available in Gearset and there is no status until the deployment complete. It would be great to bring this back to Gearset, so the tool provides the full deployment scope. Since this has been removed, I now have to open an additional page to monitor progress in Salesforce.

It'd be great to see the "Friendly Name" in the Deployment Summary page.

e.g. https://app.gearset.com/finished?deploymentId=XXXXXXXXX

And to be able to add/edit the Friendly Name on that page, same as it can be done in the Deployment Summary.

Our use case: We audit all our deployments to make sure they have a name. It would be very helpful to be able to send a Deployment Summary link to a user to tell him to add a name if it's missing.

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

If I need to find when a specific thing was changed in our system, my only option is either to use the last edited date or to manually check every daily comparison from Monitoring to see if it changed. Since many metadata types do not reliably update the last edited date, it makes it much harder to find those changes. If I could choose a specific metadata record and use that to search the Monitoring to see when it changed, it would be much easier to find it.

I have a small laptop monitor, so screen space is pretty valuable to me when working from home. It can be difficult to do code reviews from a laptop monitor because of the middle bar, which takes up a significant amount of real estate.

I rarely use any of the controls or information in that box. It would be great to be able to collapse or hide it to allow more space for the top panel (list of metadata components) and the bottom panel (selected metadata contents)

Inline Editing of metadata
In order to make our deployment successful we had to download the package, modify the version numbers on the flow definitions, and then compare the local package to the target org. It would be very helpful if we can edit the metadata XML in the UI so we can fix the version numbers.

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 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.

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.

Allow designated users the ability to modify and start backups without being the owner of the connected org or the person who created the backup.

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

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