Skip to main content

​
Overview

There are two directions for walking the BOM graph:
  • BOM explosion (forward) — starting from an assembly, expand it into every component, sub-component, and raw material it consumes, all the way down to the leaves.
  • Where-used (reverse) — starting from a component, trace every parent assembly that consumes it, optionally all the way up to the finished goods that ultimately depend on it.
Both operate on the same directed acyclic graph of BOMs. Explosion answers “what goes into this?”; where-used answers “what depends on this?” and “if I change this, what moves?”.

​
Where to Reach Them

​
On the BOMs page

The BOMs page supports both directions interactively:
  • Open any BOM to expand its component tree down to the leaves, with the per-edge quantity at each level.
  • From any BOM, run where-used to see every parent assembly that consumes it.
This is the everyday surface — click through when you’re browsing.

​
Through Dexter

For questions posed in natural language, or when you want the answer pulled into a chat, ask Dexter:
  • “What goes into widget-assembly?”
  • “Show me the BOM tree for the standard bracket.”
  • “Where is steel-plate used?”
  • “If I change the steel-plate BOM, what’s affected?”
Dexter activates the BOM Explosion workflow and runs one of two scripts against your factory’s BOMs:
  • explode <bom-slug> — forward explosion of a BOM
  • where_used <bom-slug> [--recursive] — reverse explosion of a BOM
The resulting tree or list appears in the chat, and Dexter can follow up with impact analysis, exports, or downstream questions in the same turn.

​
Inputs

Both tools take a BOM slug — the identifier of a specific BOM node in the graph, not an entity name. The slug matters because one entity can have many BOMs. A bracket entity with a standard variant and a heavy-duty variant lives as two BOMs, each with its own component tree: bracket-standard and bracket-heavy-duty. To explode the standard bracket, you pass bracket-standard.
There is no separate “variant” input — variant selection is which BOM slug you name. If you know the entity but not the slug, look it up on the BOMs page first, or ask Dexter to resolve the entity and variant to a slug.
where_used takes one flag:
  • --recursive — walk the full ancestor chain up to the top-level SKUs. Without it, where_used returns only the direct parents — the BOMs that list the target as an immediate component.
Neither tool takes a production quantity. Outputs show per-edge quantities as authored; if you need totals for a specific production volume, multiply the leaf quantities by the number of finished units yourself, or ask Dexter to do it.

​
Outputs

​
explode — component tree

An indented tree rooted at the target BOM, drawn with monospaced box-drawing characters (├──, └──, │) — text tree art, not a table with columns. The root line is <bom-slug> explosion: and carries no quantity or depth of its own. Each node below it shows its BOM slug, the quantity consumed by its parent (×N), and its depth from the root. Depth 1 is a direct component; depth 2 is a component of a component; and so on down to the leaves.
The quantities on each edge are per one unit of the immediate parent, as authored on that parent BOM. To compute the total quantity of a leaf material required for one unit of the root, multiply the per-edge quantities along the path from root to leaf. When the same leaf appears under multiple parents (a shared component), sum those path-products to get the leaf’s total roll-up.

​
where_used — parent list

A flat list of every BOM that consumes the target, with the quantity consumed per parent. Direct parents only (default):
Recursive — every ancestor up to the SKUs:
The recursive header line changes to <bom-slug> is used in (recursive): — the (recursive) marker tells you which mode produced the list. The output stays a flat list either way; ancestors beyond the direct parents are simply additional rows, not a nested tree. depth 1 is a direct parent; deeper entries are further ancestors. The ×N on a recursive entry is the quantity consumed at that specific level, not the roll-up from the leaf.

​
Step-by-Step

​
Exploding a BOM

  1. Identify the BOM you want to explode. If you know the entity but not which variant, open the entity on the BOMs page first and pick the variant that matches the configuration you care about.
  2. On the BOMs page, click the BOM to expand its tree — or ask Dexter “explode <bom-slug>” or the equivalent in plain English.
  3. Read the tree top-down. Direct components are depth 1; leaves have no further children and are your raw-material demand.
  4. If you need totals for a specific production quantity, multiply per the path rule above — or ask Dexter to compute rolled-up leaf quantities for N units.

​
Finding where a BOM is used

  1. Identify the BOM you’re changing or investigating.
  2. On the BOMs page, run where-used on it — or ask Dexter “where is <bom-slug> used?”.
  3. Start with the direct-parents view for a quick impact scan; use the recursive view to see every finished good downstream of the change.
  4. Before editing a widely-consumed BOM, review each direct parent — changes propagate to every parent that consumes it, and to every scenario run against a planning model whose BOM list includes them.
Make where-used a habit before editing any shared component. Direct-only output will miss indirect impact — add --recursive when you need every affected finished good.

​
Limits and Caveats

  • Slug in, slug out. Both tools address BOMs by slug; entity names and variant descriptions are not accepted as inputs.
  • No quantity multiplier. Neither tool takes “how many finished units” as an argument. Multiply per-edge quantities yourself, or hand the roll-up to Dexter.
  • No variant resolution against a demand line. The tools do not take a variant condition and pick the matching BOM — they walk the specific BOM you name. Variant resolution happens on planning inputs via subset matching, not here.
  • Shared components appear multiple times in an explosion. A leaf consumed by two branches shows up under both — the tree shows every path a component sits on, not a de-duplicated set. Sum across appearances for a single roll-up figure.
  • Cycles are impossible. A material can’t be part of its own BOM — cyclical dependencies are rejected on write, so traversal always terminates.
Explosion reflects BOMs as authored — it doesn’t know about a planning model’s BOM list, on-hand inventory, or supply orders. For “how much do I actually need to produce to fulfill this demand?” run a planning scenario; the optimizer accounts for inventory, supply, and resource constraints.
BOM edits are visible immediately: both tools read the current BOM graph, so a change lands in the next explosion or where-used call. Planning runs, by contrast, take effect on the next run — see Planning Runs.