Fixing "fullName invalid at this location" in package.xml

August 3, 2026

You run a Metadata API deploy - sf project deploy start, Workbench, or a CI job - and Salesforce rejects the whole thing before validating a single component:

Error: Element {http://soap.sforce.com/2006/04/metadata}fullName invalid at this location in type Package

Nothing is wrong with your components. The problem is one line in your manifest.

What <fullName> does in package.xml

package.xml describes what's in a deploy or retrieve. Most elements are what you'd expect: <types> blocks list components, <version> pins the API version. But <fullName>, directly inside <Package>, does something different from everything around it: it names an actual package - telling Salesforce to create or update a package container with that name in the target org, with your components as its contents.

Two things go wrong with it:

Placement. The Metadata API's schema is order-sensitive: if <fullName> appears anywhere except as the first element inside <Package>, the manifest fails schema validation - that's the "invalid at this location" error, and it fires before any component is looked at.
Presence. Even correctly placed, it changes what your deploy means. Instead of "deploy these components," you're saying "make these components a package named X." Retrieves of that org can start carrying the package name back, tooling that expects unpackaged metadata gets confused, and deploys can fail against orgs where the name conflicts.

The subtle way this bites: a retrieve can hand you the landmine. If someone once created a package in the source org, a retrieved package.xml may include its <fullName> - and every deploy you build from that manifest carries it along until it errors somewhere downstream.

The fix

For a normal deploy, delete the <fullName> line entirely. A minimal, always-valid manifest:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>EscalationService</members>
        <members>EscalationServiceTest</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>Escalation__c</members>
        <name>CustomObject</name>
    </types>
    <version>62.0</version>
</Package>

Keep <fullName> only when you genuinely intend to create/update a named package - and then it must be the first element.

Two neighbors of this error worth knowing

Element order matters everywhere in metadata XML, not just here. "Invalid at this location" on any element usually means it's out of schema order, not that it's unsupported.
<version> mismatches produce quieter failures: a manifest pinned above the org's API version, or components using features newer than the pinned version, fail per-component instead of up front.

---

OrgTide generates every deploy and package manifest itself - correctly ordered, unpackaged, version-pinned - whether you deploy through its gated pipeline or download a draft or release as a zip for the sf CLI. How deploys work →