Error overview
You may run into this validation error when validating deployment package that includes Static Resource(s) component(s).
An example of the error message reported in our app looks as below:
"Cannot modify managed object: entity=StaticResource, component=<component ID>, field=Body, state=installed"
This error shows up under the StaticResource metadata type, and the affected component is typically named something like <namespace>__<ComponentName>. In this example it is a Static Resource bundled inside an installed managed package.
We've seen this issue with Static Resources belonging to different managed packages, so the underlying cause isn't related to a specific vendor's package.
Explanation of the error
Once a managed package is installed in an org, Salesforce locks the internal components that ship with it (including any Static Resources the package bundles) and doesn't allow modifications of these components through the Metadata API.
This behavior is enforced by Salesforce, not by Gearset, and it applies regardless of whether the Static Resource's content actually differs between your source and target environments.
The same underlying restriction applies to "Cannot modify managed object" error that we have documented for PermissionSet metadata. In both cases Salesforce won't let your deployment package overwrite a component that belongs to an installed package.
The only supported way to update a managed package's own files is for the vendor to release a new package version that you can install or upgrade in Setup, rather than by trying to deploy metadata directly to an installed package.
Because these components are locked outright, they don't need to be part of your deployment in the first place. The most common way they end up there is by accident. For example, a StaticResource metadata filter that's broader than it needs to be, so a managed package's internal files get included in a comparison or CI deployment package alongside the changes you actually intended to deploy.
Resolution
Since Salesforce won't allow these components to be modified regardless of what you do in Gearset, the fix is to stop them from being included in the deployment package.
Workaround in Compare and deploy
Follow below steps if you're making a direct org to org, or Git to org deployment (this typically applies when you're not promoting a PR via Gearset Pipeline):
In the comparison results, find the failing Static Resource component(s) and exclude them from your filter.
Once Static Resources are excluded, you're ready to re-run the validation.
If you want to stop these appearing in future comparisons, we recommend adding a custom metadata filter that excludes
StaticResourcecomponents under the managed package's namespace (or exclude the specific components by name, e.g by using regex).
Workaround in Gearset Pipelines
If you're validating a pull request (PR) via your Gearset Pipeline, follow these steps to fix the issue:
On CI jobs page, click on the CI job targeting the affected Pipeline environment, then navigate to Edit settings and Metadata filters tab (on the left hand side).
Remove the failing Static Resource component(s) from the filter used for this CI job.
Alternatively, you may consider removing the managed package namespace from your CI job's filter - if that package doesn't need to be promoted to upstream Pipeline environments, and/or isn't required to be tracked in your VCS. Although, normally removing Static Resources from the filter is a workaround good enough.
Once metadata filter for the CI job is amended (or package excluded from the filter), re-run your PR's validation in the Pipeline.
Fix for when a PR had been merged successfully and CI job deployment failed
On the screenshot at the top of this article, we're showing a failed deployment to the target org after a PR had been successfully merged to the source branch in the affected Gearset Pipeline.
This likely means that some of your actual changes (e.g. whatever has been merged via the PR) never made it to the target org of your CI job. You can verify if that's true by running a comparison in Compare and deploy between the source branch and the target org of your CI job (e.g. INT branch > INT org).
If this applies to your use case, follow these steps to fix the issue:
Run a Compare and deploy between the same source branch and the target org (e.g. INT branch > INT org), make sure to use the same metadata filter as the filter used in the CI job.
Deploy the remaining differences (typically New and Changed items), or cherry pick the changes that belong to your PR and deploy them to the target org.
This way you're ensuring that the target org of the CI job is up to date with any changes that were merged via the PR into the source branch, but didn't make it to the org because of a failed deployment.
Further insights on Pipeline diagnosis
This issue is worth analysing closely if your team has recently expanded a CI job's metadata filter. For example, after a Pipeline notification warned that some changes (such as Static Resources) wouldn't be deployed and suggested updating the filter.
Expanding the filter for CI job(s) to include Static Resources generally can unintentionally pull a managed package's internal files into your next deployment package and may result in this type of validation error.
Disclaimer: This validation error is generated by Salesforce during deployment validation, not by Gearset. Gearset surfaces the error to help you identify and resolve the underlying metadata issue before deployment, but the validation rule itself, and what Salesforce will or won't accept, is controlled by Salesforce.