"Is this the same customer?" and "who does this customer roll up to?" sound like variations on the same question. Computationally, they aren't. The first is a pairwise comparison problem — take two records, decide how similar they are. The second is a traversal problem — starting from one entity, walk a network of relationships to answer a question about structure. Systems built to do the first one well are usually not built to do the second one well, and platforms that try to force a single engine to handle both tend to be mediocre at each.
Two different kinds of question
Matching questions are local: given record A and record B, how confident are we they represent the same entity? The answer depends on comparing attributes — names, addresses, identifiers — and doesn't inherently require knowing anything about a third record.
Hierarchy and relationship questions are structural: given entity A, what entities are connected to it, how many steps away, and through what kind of relationship? Answering "show me every account under this parent organization, three levels down, including recently acquired subsidiaries" isn't a comparison — it's a graph traversal, and it gets computationally expensive fast on a system that wasn't built to do it.
Where enterprises feel this most
- Channel and partner hierarchies — commission structures, sub-partner relationships, and territory or store rollups all require multi-hop traversal, not record-to-record comparison.
- Corporate family structures — parent/subsidiary relationships that matter for exposure aggregation and credit limits change over time and require walking a structure, not scoring a pair.
- Household and account relationships — who's related to whom, and how that affects bundling or shared context, is inherently a network question.
A platform that tries to answer these questions by layering hierarchy logic on top of a relational matching engine tends to hit two walls: query performance degrades sharply as traversal depth increases, and the data model itself resists representing relationships that change shape — a subsidiary gets acquired, a partner moves to a new channel — without a rewrite.
Why keeping them separate is a design decision, not a limitation
The practical implication isn't that hierarchy questions are unsolvable inside a matching-first platform — it's that solving them well usually means routing them to a purpose-built graph layer rather than forcing the matching engine to do double duty. The matching engine stays fast and simple because it only has to answer one kind of question. The graph layer stays fast because it only receives the data it actually needs to answer traversal questions — typically the resolved entities and the relationships between them, not the full record set.
A system that's good at everything is usually mediocre at the two things that matter most.
For enterprises evaluating an MDM platform, this is a useful question to ask directly: when a hierarchy changes — an acquisition, a re-org, a partner reassignment — does the platform handle that as a natural update, or does it require reworking match rules that were never designed to represent structure in the first place?