What does this error mean?
package.xml is the list of what you promise to deploy. Salesforce opens the zip, walks that list, and fails on any member that has no file behind it. The error names the type and the member, so you know exactly which line to look at.
A manifest that lists one missing class, one missing field and one missing object returns three lines:
An object 'InvoiceSyncHelper' of type ApexClass was named in package.xml, but was not found in zipped directory
An object 'Account.Partner_Tier__c' of type CustomField was named in package.xml, but was not found in zipped directory
An object 'Site_Visit__c' of type CustomObject was named in package.xml, but was not found in zipped directory
What causes it?
- A typo between the member name and the file name. Check spelling and case, especially for fields written as
Object.Field__c. - The file is not in the folder. In metadata format, classes live in
classes/, objects inobjects/, and the meta-xml files must sit next to the source file. - A type that lives in folders (reports, dashboards, email templates) was listed without its folder, such as
MyFolder/MyDashboard. A Dashboard version of this error is on Stack Exchange. - The component was deleted, renamed, or never retrieved, and the manifest is old.
- The reverse mistake: a file is in the zip but not in
package.xml. That givesNot in package.xmlinstead.
How do I fix it?
There is no Setup screen for this one, because the manifest is a file. For change sets, the package is built for you, so this error is a CLI and API problem.
- Copy the type and member from the message.
- Search your project folder for that name. Check the spelling, the case and the folder.
- If the file exists, make sure the type matches and the file sits in the right folder. The same error shows up for Lightning web components, such as a bundle called pubsub in this question (Salesforce Stack Exchange).
- If the file is gone, remove the member from
package.xmlor retrieve the component again. - Run the check again.
sf project deploy start --metadata-dir mdapi --dry-run --test-level NoTestRun -o target-org
With a source-format project, the CLI stops earlier. When none of the manifest members have source behind them, it prints No source-backed components present in the package. Fix it the same way, by checking names against the files.
How do I prevent it?
Generate the manifest from the project instead of typing it. sf project generate manifest --source-dir force-app writes a package.xml from the files that exist. Commit it with the source. Keep one manifest per release, not one file you edit forever.
When your list is long, split it. Deploy the objects and fields, then the classes, then the profiles. A smaller package makes the guilty line easy to find. If you would rather skip hand-made manifests, AI Salesforce deployments builds the bundle from a diff of the two orgs. The change set errors guide covers the no-code route, and the sandbox glossary entry explains where the source usually comes from.
Questions about package.xml errors
What is the difference between Not in package.xml and was named in package.xml but was not found?
Opposite directions. Not in package.xml means a file is in the zip and the manifest does not list it. Was named but was not found means the manifest lists it and no file exists.
Can I use a wildcard to avoid the error?
A wildcard means every component of that type in the folder, so it has no single missing name to complain about. It also deploys more than you may intend, so we would name members for anything risky.
Does this error happen with change sets?
Rarely. Salesforce builds the package from the items you add, so a missing component usually shows up as a dependency message instead.
Why does it name a component I never touched?
A manifest is often copied from an older release. Remove members you no longer ship.