SAP Where-Used List: What It Misses and What to Do

Decision context

The where-used list is the first thing every ABAP developer reaches for and the reason a lot of impact analysis is wrong. It is accurate about what it covers, and what it covers is static, declared references that the cross-reference index knows about.

Two things make it incomplete. The index has to be current, and a stale index quietly returns fewer hits rather than an error. And a large family of ABAP call patterns are resolved at runtime, so there is no static reference for the index to hold.

None of that makes it a bad tool. It makes it a first step. The point of this page is the second step: knowing exactly what the list cannot see, so an impact assessment says so instead of implying completeness.

Getting a complete answer from the tool itself

Before worrying about what it cannot see, make sure it is showing everything it can. Most incomplete where-used results are configuration rather than limitation.

• The scope dialog restricts which object types are searched. A default scope that excludes classes, interfaces, or dynpros produces a confident and wrong answer.
• The cross-reference index has to be built and kept current by its background job. If the index has not run since the last transport wave, recent references are missing.
• For a table field, search on both the field and the underlying data element. They return different sets and both matter.
• For a domain or a data element, the list is often large and mostly irrelevant. Restrict by package or software component rather than by giving up.
• Cross-system references do not appear. A where-used list answers for the system it runs in, not for the landscape.

The five patterns it cannot see

These are resolved at runtime, so there is no static reference. Every one of them is common in older custom ABAP, and each needs a different second check.

• Dynamic calls. A function module, method, program, or form called through a variable holding its name. Nothing static points at the target. Find these with a source text search for the calling construct, then read the code around it.
• Dynamic data access. A select or an assignment using a table or field name held in a variable. The table has no recorded reference from that program at all.
• Generated and downloaded code. Objects generated at runtime or by a framework are not in the index in the way a written object is.
• Configuration-driven dispatch. A table entry that decides which routine runs. The reference is in the data, so no code analysis will find it and the table has to be read.
• External callers. RFC, web service, OData, and IDoc consumers live in another system or another organisation. The where-used list has no visibility of them, and this is where interface breakage comes from.

The second checks worth doing

Each of these costs minutes and closes a specific blind spot. Doing all five is a reasonable definition of due diligence for a change to a shared object.

• A source text search across custom code for the object name as a string, which is how dynamic references become visible.
• Runtime usage data where you collect it, which answers what is actually executed rather than what refers to it. This is the only check that distinguishes live code from dead code.
• Configuration tables that hold object names, which need reading directly since no code analysis reaches them.
• The interface inventory, for external consumers of the structure or the data being changed.
• The enhancement and BAdI implementations attached to the object, which are references of a different kind and are easy to miss when the search scope is set narrowly.

What the workflow must cover

• Beyond static references. Combine declared references, source text evidence, configuration content, and observed runtime behavior into one impact view.
• Observed versus inferred. Label how each dependency was established, so confidence is visible rather than implied by the presence of a row.
• Landscape scope. Include interface consumers that live outside the system the where-used list can see.
• Named blind spots. Report the dynamic and configuration-driven patterns that could not be resolved, as an explicit output of the analysis.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Confirm the cross-reference index is current before trusting a result.
2. Run the where-used list with an object type scope that covers everything relevant.
3. Search custom source text for the object name to surface dynamic references.
4. Check configuration tables and the interface inventory for non-code references.
5. Record what could not be resolved as a named gap rather than as an absence of impact.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Index build status and date
• Object type scope used
• Where-used result set
• Source text search hits
• Configuration table references
• External consumer list
• Runtime usage evidence
• Unresolved patterns named

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A where-used list is accurate about static declared references and silent about everything else.
• A stale cross-reference index returns fewer results without any indication that it is stale.
• Runtime usage evidence requires collection over a representative period, including period-end and year-end, or seasonal code looks dead.

Buyer checklist

• When was the cross-reference index last built?
• Was the object type scope wide enough?
• Has custom source been searched for the object name as text?
• Which configuration tables reference this object?
• Which external systems consume this structure?