Start with what one row means
An XML document can describe orders, order lines, payment events and notes in one tree. A spreadsheet needs a clear record level. If you want an order register, select the order element. If you want a line-item list, choose the repeated line element instead. The suggested choice follows structural repetition and depth; it cannot determine your reporting goal.
Run the built-in example and select the order element. Two orders become two root rows. Their lines and payments become separate child tables. Change the record selector to line and notice that the root table now describes individual lines. The source-parent identifier still indicates which XML element contained each line, but that parent may lie outside the selected table.
Keep independent child lists separate
Flattening an order with two lines and two payments into every possible combination produces four rows. Repeated order totals can then look larger than the source. Related-table mode avoids that Cartesian product: each child row receives a parent ID and appears exactly once in its own table.
The generated $id values are stable positions in this parsed source document. They are useful for joining these exports, not permanent customer or order keys. Preserve any actual business identifier as its own attribute or element column. If the source document changes, do not assume these generated IDs remain the same.
Check a representative slice
Inspect the first records, a record with multiple children, and one with missing optional values. The preview distinguishes an empty string from a missing field. The Mapping worksheet counts both per column; JSON distinguishes an existing empty string from an absent key.
If you prefer one table, choose JSON-array mode. Repeated child groups stay as structured JSON text in a column. This avoids duplicate rows but requires a downstream JSON-aware workflow. It is a deliberate data shape change, not a claim that one row can express every relationship as ordinary scalar cells.