7 min read
Edit a Salesforce Commerce Cloud (SFCC) catalog XML in Excel
By Quentin Delepierre, Salesforce Commerce Cloud consultant
Business Manager imports and exports XML; catalog teams work in Excel. This guide shows how to go from one to the other without a script: what your products, prices and stock look like in the spreadsheet, and how to import the result back.
Business Manager only speaks XML
In Salesforce B2C Commerce (SFCC, formerly Demandware), catalogs, price books, inventory lists and content libraries are imported and exported as XML, following the platform's schemas.
Yet bulk changes arrive in spreadsheets: translations to rework, online dates to shift, attributes to fill in, prices to fix. Without a tool, you're left with two options: have a developer write the XML, or edit it by hand in a text editor, at the risk of an import rejected for one badly closed tag.
Which SFCC exports work
- Catalog (products and categories): one row per product. If the file also holds categories, a _type column tells for each row whether it's a category or a product. To work on products only, choose product through "Not the right row?": categories are no longer in the CSV, but they stay as they are in the rebuilt XML.
- Price book: the preview offers one row per price (price-table), with the product ID and the amount. For a tiny price book of a few prices, it may show a single row: then pick price-table through "Not the right row?". The price book header (ID, currency) is kept as is and written back on reconstruction. A file holding several price books has to be split, one price book per file.
- Inventory list: one row per product (record) when the file holds a single warehouse. If it holds several, the preview offers one row per warehouse: for one row per product, type record in "Another tag", under "Not the right row?". A column then gives the warehouse ID and each one keeps its own header.
- Content library: folders and content assets, with the same _type column as the catalog.
What the CSV looks like
Each element or attribute of the product becomes a column. Translated values get one column per language: display-name[fr-FR], display-name[x-default]. XML attributes start with @: @product-id. In the CSV file, these headers are written with an apostrophe in front ('@product-id), a protection against formulas: leave it, the reconstruction removes it. Flags such as online-flag stay true / false columns.
Repeated elements are numbered in file order: images.image-group[0], images.image-group[1]…, each with its .@view-type column.
<product product-id="25502228">
<ean>5060155242347</ean>
<display-name xml:lang="x-default">Striped Silk Tie</display-name>
<display-name xml:lang="fr-FR">Cravate en soie rayée</display-name>
<online-flag>true</online-flag>
<brand>Marquee</brand>
</product>@product-id , ean , display-name[x-default] , display-name[fr-FR] , online-flag , brand
25502228 , 5060155242347 , Striped Silk Tie , Cravate en soie rayée , true , MarqueeCustom attributes
When each custom attribute appears only once per product, its ID becomes the column name: custom-attributes.custom-attribute[refinementColor]. That's the simple case.
A translated attribute (the same attribute-id in x-default and fr-FR) gives one column per language, like texts do: custom-attributes.custom-attribute[seo_url][x-default], custom-attributes.custom-attribute[seo_url][fr-FR]. Each column holds the same attribute for every product: a bulk edit happens right in the column. To add a translation to a product that has none, fill its cell in that language's column: the reconstruction creates the tag with its attribute-id and xml:lang. Only languages present in the export have a column.
One exception: if the same attribute appears twice in the same language for a product, the block is numbered, in file order. Each attribute then takes several columns: its name (custom-attribute[0].@attribute-id), its language (@xml:lang) and its value (custom-attribute[0]), and the same number can point to a different attribute from one product to the next. Read the name in the @attribute-id column next to it and filter on that column before changing anything: reconstruction always puts the value back under the right attribute. The standalone Excel workbook still numbers translated attributes this way.
The steps
- Export the object from Business Manager (catalog, price book, inventory or library) and get the XML file.
- Drop it on the ExcelifyXML Upload page. The free preview shows the detected row, the number of rows and columns, and the first values. Check there's one product (or price, or stock record) per row, then confirm (1 credit).
- Open data.csv in Excel. If the file holds EAN or UPC codes, import them as Text (Data › From Text/CSV) so Excel doesn't change them.
- Make your edits: values, translations, dates, rows added or deleted.
- On the Rebuild page, choose "Separate files" and drop the edited data.csv with its skeleton.json. You get the XML back, with the original file's root, namespace and header.
- Import it into Business Manager, on a sandbox or test environment first.
Importing back into Business Manager
- Choose the import mode knowingly. Merge updates what the file contains and leaves the rest in place; Replace replaces each object with its version from the file. For a bulk change on a full file, Merge is the cautious choice.
- Business Manager validates the file against the schema before importing and lists errors in the log: always start on a test environment.
- A row deleted from the CSV disappears from the XML. In Merge mode, that doesn't delete the product in SFCC: it simply isn't changed.
- Empty self-closing tags without attributes (<upc/>) are dropped on the way through the CSV: the preview warns you when your file has some. A self-closing tag that carries an attribute is kept.
Pitfalls ExcelifyXML handles for you
- Booleans: Excel rewrites true / false as TRUE / FALSE (VRAI / FAUX in French, WAHR / FALSCH in German), which the SFCC schema rejects. In columns that held only true / false, reconstruction puts the values back in lower case.
- Carriage returns: the in descriptions and JSON attributes are kept, exactly as in the original file.
- EAN and UPC codes: if Excel turned one into scientific notation (3.61235E+12), reconstruction stops and shows the column and rows at stake, instead of producing a wrong catalog.
- ISO dates (2026-09-01T00:00:00.000Z): Excel leaves them as text, they come back as they were. A date rewritten in another format stops the reconstruction.
- HTML descriptions: values containing markup are written back as CDATA, so the XML stays valid.
What about large catalogs?
An SFCC catalog export quickly exceeds 4 MB. The free plan transforms up to 4 MB, the VIP plan up to 30 MB. Beyond that, or to spend a single credit, transform a sample that holds every field in use, then rebuild the full file with the same skeleton.json.
Turn your Business Manager export into an editable CSV:
Transform a file