All Collections
Problem analyzers
Remove components added to standard objects by managed packages
Remove components added to standard objects by managed packages

Managed components can only be deployed by package upgrade or installation in your target org

David Runciman avatar
Written by David Runciman
Updated over a week ago

This problem analyzer helps you increase the likelihood of a successful deployment by automatically removing from your deployment any components added to standard objects by managed packages.

What triggers this problem analyzer?

Large and feature-rich applications that are made available through the Salesforce AppExchange sometimes add components, such as custom fields, to standard objects. As these components can’t normally be added, removed or changed by deploying metadata, Gearset will alert you to this and give you the option to remove the components in question from your deployment.

What problem does it solve?

Differences occur in comparisons if the version of an installed managed package differs between the source and target org. The metadata API provides the facility to request metadata excluding managed packages, but this doesn’t apply to managed components added to standard objects. If you attempt to deploy changes to such managed fields, your deployment is likely to fail with an error message such as the following:

Cannot modify managed object: entity=StaticResource, component=0814J000000pP6E, field=Body, state=install.

How does it work?

Gearset removes managed fields on standard objects from your deployment package to ensure the success of your deployment. We recommend that you follow the best practice of installing all the managed packages referenced in the deployment package in the target, and checking that the same versions are installed across both source and target.

Source XML example

The code example below shows two fields that were added to a standard object. The first, New_Unmanaged_Field, is a normal unmanaged field that was added to the standard object by a user. The second, sma_MABetaTester, is a managed field that was added to the same standard object by a managed package.

<?xml version="1.0" encoding="utf-8"?><CustomObject ">xmlns="http://soap.sforce.com/2006/04/metadata">
    <fields>
        <fullName>New_Unmanaged_Field__c</fullName>
        <description>A new unmanaged field.</description>
        <externalId>false</externalId>
        <label>New Unmanaged Field</label>
        <length>48</length>
        <required>false</required>
        <trackFeedHistory>false</trackFeedHistory>
        <type>Text</type>
        <unique>false</unique>
    </fields>
    <fields>
        <fullName>sma__MABetaTester__c</fullName>
        <defaultValue>false</defaultValue>
        <deprecated>false</deprecated>
        <externalId>false</externalId>
        <label>MapAnything Beta Tester</label>
        <trackFeedHistory>false</trackFeedHistory>
        <type>Checkbox</type>
    </fields>
    </CustomObject>

Modified XML deployed

If you allow Gearset’s problem analyzer to exclude the managed field before running the deployment in the above example, Gearset will only deploy the first (unmanaged) field.

<?xml version="1.0" encoding="utf-8"?><CustomObject ">xmlns="http://soap.sforce.com/2006/04/metadata">
    <fields>
        <fullName>New_Unmanaged_Field__c</fullName>
        <description>A new unmanaged field.</description>
        <externalId>false</externalId>
        <label>New Unmanaged Field</label>
        <length>48</length>
        <required>false</required>
        <trackFeedHistory>false</trackFeedHistory>
        <type>Text</type>
        <unique>false</unique>
    </fields>
</CustomObject>

Why the problem analyzer may not be applied

If you have managed field on a standard object, but this problem analyzer is not being applied to remove it, check its difference type and whether you have the Installed package metadata type included in your comparison.

If the difference type of the managed field is Different (it's in the Changed items tab), we look to see whether the versions of the managed package are different on the source and target. We can tell what versions the managed packages are by the Installed package metadata type.

If we see the versions are different, we assume that the difference in the field is due to version, and then that triggers the problem analyzer to exclude the fields.

However, if we can't see that the managed package versions are different, then we can't tell if the change to the field has been made by the user or if it is due to the version difference, and so the problem analyzer doesn't remove it.

If the field is New or Deleted and the target contains the package, the problem analyzer will be applied, regardless of package version.

Did this answer your question?