Where-used, under stated conditions
“Which products contain this part” has at least four correct answers depending on what you meant. The useful ones are scoped — as of today, in what ships, at this plant — and the useless one is every structure that has ever mentioned it.
What it is, and what it is not
The inverse of a bill of materials: given a part, which structures reference it, and which finished products those roll up to. Single-level returns immediate parents; multi-level walks to the top.
It is not a text search for a part number. That returns every document, note and superseded revision mentioning the string, which is a different question with a much larger and less useful answer.
It is also not a static index. A where-used answer depends on when you are asking, which configuration you mean and which plant builds it — so it is computed through the resolver rather than looked up in a table that would have to be rebuilt on every change.
The mechanism: the scope is the answer
The same part, asked four ways, gives four legitimately different answers. Which structures mention it anywhere includes superseded revisions and abandoned concepts. Which are effective today excludes them. Which ship narrows to released products in production. Which shipped in March is a different set again.
The figure above is the common case and the one people get wrong. Three immediate parents, but one exists only in a superseded revision — so single-level where-used returns three and multi-level returns two shipping products. Both numbers are correct answers to different questions, and reporting the first as though it were the second is how a change gets scoped too widely and then dismissed as noise.
Multi-level walks through purchased sub-assemblies too. A connector three levels down inside a bought-in module still resolves to the finished products it affects, which is precisely the case a manual search misses because nobody thinks to open the module.
Quantities roll up on the way. A screw used four times in a housing that appears twice in a product is eight, not one — and that number is what makes an end-of-life exposure calculation mean anything.
The failure it prevents
A supplier discontinues a connector. Somebody searches the PLM for the part number and gets seventeen hits. Most are old revisions and two are documents.
Working out which of the seventeen matter takes an afternoon, and the conclusion is “four products” — of which one turns out to be a service kit that has not been built in three years and one is a variant sold only in a market the company exited. The real answer was two, and the two-day scoping exercise produced a change request three times larger than it needed to be.
The opposite failure is worse. The search misses a product entirely because the part sits three levels down inside a purchased sub-assembly, and nobody expanded it. That product keeps building until the connector runs out.
How it meets the rest of the product
Where-used, compare, cost rollups and impact analysis all read the same resolver, so a line the cost rollup counted is a line where-used will report. Consistency here is structural rather than something to be maintained.
Impact analysis is where-used with the other relationship types included — documents that specify the part, requirements it verifies, approved manufacturer entries, open changes already touching it. Where-used is the structural subset, and both traverse the same graph.
Results are permission-filtered on the way out, and the count comes from the same clause as the rows. A where-used result never reveals the existence of a restricted programme through a total that does not match what is listed.
Saved as a view, a where-used query is shareable by user, team, role or tenant — so the scoping question somebody worked out once stops being re-derived slightly differently by four other people.
How it meets your ERP
Where-used answers the engineering half of an exposure question; your ERP answers the operational half. A part in two shipping products is a scope; the same part with eleven weeks of stock and two purchase orders in flight is a decision.
So results carry ERP context where the connector provides it — on-hand, committed, open orders and lead time against each affected product — cited with the source system and an as-of stamp because they are cached reads of somebody else's master record.
The distinction matters in the other direction too. An ERP's own where-used runs over the production BOM it holds, which is the manufacturing structure, not the engineering one. Both are legitimate and they answer different questions — which is exactly why the system-of-record matrix names an owner per object rather than assuming one view is the truth.
Where the boundary is
It reports structural containment, not consequence. Two products containing a part are two products; whether changing it is expensive depends on qualification state, customer commitments and tooling, none of which where-used claims to weigh.
It also cannot see relationships that were never recorded. A part used in a fixture documented only in a drawing note is not in the graph, and the honest report is that nothing was found rather than that nothing exists.
Facts
| Modes | Single-level and multi-level, over resolved structures |
| Scoping | As-of date · configuration · plant · shipping only |
| Purchased sub-assemblies | Walked through — the case manual searches miss |
| Quantities | Roll up — four per housing, twice per product, is eight |
| Superseded revisions | Excluded from effective answers, reported separately |
| Permissions | Filtered on the way out; counts match the rows |
| ERP context | Stock and open orders per affected product |
| Reports | Containment, never consequence |
Frequently asked
Why does where-used need a date?
Because the same part gives four legitimately different answers: structures that mention it anywhere, those effective today, those in shipping products, and what shipped in March. Reporting the first as though it were the third scopes a change three times too widely.
What is the difference between single and multi-level?
Single-level returns immediate parents; multi-level walks to the finished products. In the figure above the same part gives three parents and two shipping products, because one parent exists only in a superseded revision — both numbers are correct answers to different questions.
Does it look inside purchased sub-assemblies?
Yes, and this is the case manual searching reliably misses. A connector three levels down inside a bought-in module still resolves to the finished products affected, because nobody thinks to expand a module they did not design when scoping a change by hand.
Are quantities rolled up?
Yes. A screw used four times in a housing that appears twice in a product is eight, not one. That number is what makes an end-of-life exposure calculation mean anything — a count of products tells you scope, but a count of pieces tells you runway.
How is this different from impact analysis?
Where-used is the structural subset of it. Impact analysis traverses the same graph but includes every other relationship type as well — documents that specify the part, requirements it verifies, approved manufacturer entries, and any open change already touching any of them.
Does it match what our ERP reports?
Not necessarily, and that is correct. An ERP's where-used runs over the production BOM it holds — the manufacturing structure, not the engineering one. Both are legitimate answers to different questions, which is why the matrix names an owner per object.
Can it tell us whether a change is expensive?
No. It reports structural containment and nothing more. Whether changing a part is expensive depends on qualification state, customer commitments and tooling, none of which where-used claims to weigh. It tells you what is affected, and people decide what that actually costs.