Upgrade of 2G Managed Package failing due to Data Not Available (contentasset):

He example problem message from Salesforce email:

  1. (app_logo) Data Not Available The data you were trying to access could not be found. It may be due to another user deleting the data or a system error. If you know the data is not deleted but cannot access it, please look at our support page.

The app_logo is contentasset file - this is the App's logo and some other files, for some reason they look to have been deleted on subscribe sandbox side. Could be CI process.

Any thoughts to help resolve this and prevent in future?

At moment I have asked to see if the subscriber could refresh sandbox without deleting contentasset files.

1 Answer 1


Frustratingly, ContentAsset does not have an entry in the documentation on Components Available in Managed Packages. However, the behavior you're describing suggests that this entity is probably subscriber-deleteable.

In general, subscriber-deleteable entities should not be allowed to be deleted if they're referenced by another component in your package (assuming that referencing component is itself not deleteable). This protection isn't always implemented correctly, though. I've seen instances like the one you describe where a customer successfully deletes a component, and package upgrades subsequently fail. The case I've seen before was a Report being deleted despite being used in a Report Chart shown on a Lightning Record Page. This caused package upgrade failures.

This issue, assuming I'm right in diagnosing it based on your description, is really hard to fix. You can probably set up this situation in a mock subscriber org to see if it matches the actual subscriber issue.

There are three things I would recommend you explore here.

  1. Please open a support case with Salesforce and describe the exact circumstances (subscriber org id, currently installed version, version that will not upgrade). Make sure to specify the relationships between the rest of your metadata and that ContentAsset in the current and upgraded package versions.

  2. You may be able to help the subscriber un-delete the removed component. In the past, I have been able to do this by providing the subscriber with a metadata bundle (the actual deleted component from my managed package, including the namespace, and a package.xml manifest) and having them deploy it into their org. This does restore the deleted component, but it only works for 30 days after the subscriber's initial deletion. (You can test this in your mock subscriber org after you repro the issue).

  3. You can try to guard against it by establishing component-to-component references that protect the subscriber-deleteable component from deletion. Since you seem to have found a reference that doesn't provide protection, try other components, especially components that are not themselves subscriber-editable or -deleteable. Test with beta packages in your mock subscriber orgs to see if you can block unsafe subscriber deletes.

  • Something else to try is to remove the hard dependency in your package, and make it a dynamic dependency, if that's possible for you. Given it is an app logo, that sounds unlikely to be an option. The other suggestion I have is to update the package to include a new logo asset and update the app to reference this new one. That said, the App branding data is all subscriber editable so if they changed the logo this seems like a validation failure during the install process - it shouldn't matter that the logo was deleted since the packaged logo reference in the app would be ignored.
    – Phil W
    May 11, 2023 at 8:06
  • Thanks David, Phil for the details: Raised a case: #44579365. Initially looking to see if can just resolve with the client refreshing, may hit complications as it's their UAT org. Strangely their other sandbox orgs the ContentAssets have not been deleted. May 15, 2023 at 9:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .