Pull a metadata component from an org as XML, edit the configuration in your editor, and deploy the change back through the Salesforce CLI.
- Retrieve metadata via the CLI
Run sf project retrieve start --metadata CustomObject:Account in your Salesforce DX project. The CLI writes Account.object-meta.xml to the force-app metadata folder.
- Open the XML in your editor
Open Account.object-meta.xml in VS Code. The file is a tree of fields, validation rules, and record types in XML tags.
- Make the change
Edit the relevant tag. Add a new field, change a validation rule formula, update a label. Save.
- Validate the XML
The Salesforce extension flags syntax errors and tag mismatches inline. Fix any red squiggles before deploying.
- Deploy back to the org
Run sf project deploy start --metadata CustomObject:Account. The CLI packages the XML and posts it to the Metadata API. Deploy result lands in seconds.
- Verify in Setup
Open the org in a browser. Setup, Object Manager, Account. Confirm the change you made in XML now appears in the UI.
Salesforce API that exchanges metadata as XML; backs every CLI deploy and retrieve.
Legacy XML-envelope API for record CRUD; still supported alongside REST.
XML schema that describes the SOAP API for type-safe client generation.
Manifest file listing metadata components to include in a deploy or retrieve.
- Metadata XML is strict about tag order and attribute names. A typo or out-of-order tag fails deploy with a vague schema-validation error.
- XML namespaces matter. The xmlns attribute on the root element must be exactly the Salesforce metadata namespace URI; substitute the wrong one and the deploy refuses the file.
- XML payloads are bigger than JSON. SOAP integrations with high message volume can hit network bandwidth or API limits faster than the equivalent REST integration.
- Parsing large XML in Apex eats heap. Use Xmlstreamreader for documents over a few hundred KB; Dom.Document loads the entire tree into memory.