One of the unique features of Gearset is its understanding of your metadata, and how it can suggest improvements to your deployments to make them more likely to succeed. This guide will give a brief overview of how the problem analysis works, and how to interact with the results.

Because there are so many possible interactions, I won't document them all here! To see a list of our problem analyzers, what triggers them, and how they work, see our section on problem analyzers.

Gearset's problem analysis kicks in when you click NEXT from a comparison. At this point, Gearset will scan the components you selected and look for potential issues such as:

This analysis is performed by Gearset, and is not part of the Salesforce package testing. Your metadata is not uploaded to Salesforce at this point - this is all Gearset!

This process usually only takes a matter of seconds, but for large deployments it may take a few minutes.

If Gearset does not detect any issues with your deployment, you will be taken straight to the pre-deployment summary after clicking NEXT.

There are two types of problem analysis which you can switch between using the tabs:

Warnings are issues that Gearset cannot automatically fix by adding or removing components to your package. A common example is that some objects must be deployed in a specific order, as part of several deployments. 

To resolve a warning, you must take a separate action before proceeding with the deployment. The warning will give you more information about what to do.
​

Suggested fixes are changes that Gearset recommends making to your deployment package to make it more likely to successfully deploy. Fixes fall into one of two categories:

Fixes can be resolved by looking at the suggestions Gearset makes, and checking the boxes to add or remove components from your package. This is done in Gearset as part of the deployment flow.

Sometimes you may have added some items to your package but forgotten other items they depend on. Without including the dependencies, the deployment will not succeed.

In the screenshot below, for example, I have selected a new custom field, but forgotten to include the new custom field it depends on. Gearset has identified this, and recommends that the field it depends on also be included. 

By ticking the checkbox, the missing component will be added to my deployment package.
​
Gearset scans for a large number of these kinds of dependencies for the most commonly deployed components, including Profiles, Permission Sets, Custom Fields, Emails and many more.

Some changes cannot be easily deployed to some orgs and should be removed from your deployment package. A common example is a component of a feature that is enabled in the source, but not in the target org.

The screenshot below shows another example of a recommended exclusion, where Settings items have been selected for deletion, but they cannot be removed due to the associated feature in the source or target org not being currently enabled. Gearset notifies me I should remove the item from the deployment.

By ticking the checkbox, this item will be removed from my deployment package.

For more information on exploring the comparison results to find object dependencies, see the following two help articles:

If you wish, you can ignore all of the suggestions made by Gearset's problem analysis and proceed with the deployment unaltered. To do this, simply uncheck any checkboxes in the Suggested fixes tab and click NEXT.

You will see a warning dialogue - click Continue to summary to move forwards.

Gearset treats repositories like Salesforce orgs - when deploying metadata changes to a source control repository, Gearset will run the problem analyzers as usual to scan for issues. This is to maintain your metadata in a format that can easily be deployed out to a Salesforce org again in the future.

In some cases, however, you may wish to ignore the problem analysis when deploying to source control, as there are far fewer restrictions on what you can deploy to a repository vs a Salesforce org. To do this, simply follow the steps in the section above about overriding problem analysis and deploy as usual.