align-left
green-eyebrow
ON EBX › Use cases
/content/dam/eds-onebx-com/images/contact-us-page/Herocontact_2x.png

Hierarchy management

Bring order to complexity. Model, govern and synchronise sophisticated data relationships across every domain in your enterprise.
/content/dam/eds-onebx-com/images/contact-us-page/Herocontact_2x.png
Why it matters

Governed members, ungoverned structure

Most organisations govern the members: the cost centres, the products, the legal entities. The structure that connects them is rarely held to the same standard. Which cost centre rolls into which division, which product sits under which family, which entity consolidates into which group — that usually lives in a file on someone’s desktop, rebuilt each planning cycle and reconciled by hand.

EBX® closes the gap by treating the structure as governed data in its own right: modelled on relationships already present in your data, maintained by the people who own it, versioned, and delivered to every system that reports on it.

align-center,t-body
Fast-Forward-Arrow

One governed structure. Every number adds up.

Model any relationship, across any domain

Hierarchies in EBX® are built on the relationships already in your data, not on a rigid separate structure.

  • Multi-domain flexibility. Build hierarchies on any relationship — within a domain, between domains, or across several — without rigid schema constraints.
  • Automatic synchronisation. Hierarchies are not static lists. They are dynamic views that change as the underlying data evolves.
  • No fixed ceiling. Depth is not capped in advance, and there is no limit on how many structures you maintain in parallel.

The shapes a hierarchy can take

Business structures are rarely a clean tree, so EBX® builds hierarchy views several ways over the same governed tables:

  • Recursive hierarchies. One table whose records point at their own parent: org charts, legal entity trees, bills of materials, a chart of accounts. Depth is not fixed in advance.
  • Dimension hierarchies. Levels derived from columns the record already carries, so a product table reads as Segment → Type → Packaging, or Brand → Segment → Type → Packaging, from the same data. Foreign keys, enumerations, text, numbers and yes/no fields can each act as a level, in any order.
  • Skipped-level, or ragged, hierarchies. Real structures have gaps. A store with no state recorded still appears under its city instead of dropping out of the tree, attaching to the level above the one it is missing.
  • Time hierarchies. Any date field becomes a navigable dimension of century, year, quarter and month, so records group by the period a business actually reports on rather than by raw date.
  • Alternate hierarchies. The same members, several structures: a geographic roll-up for statutory reporting, a functional one for management, a local one for a regional regulator. Each is maintained and versioned on its own.
  • Cross-domain hierarchies. Structures that span domains, linking product, customer and location data so one view carries relationships no single system holds.
Each of these is a view over the governed records rather than a copy of them, so a correction to a member is reflected everywhere that member appears.
The same members reached three ways: by geography, by function, and by a localised roll-up. Members are usually consistent across alternate hierarchies, but not always.

Native stewardship tools

Business users maintain the structures themselves, through an interface built for scale rather than a developer console.

  • Drag-and-drop control. Move, attach and detach parents and children visually, with rules enforced automatically so structural integrity holds.
  • Semantic linkage. Link hierarchies across data domains for a single view of relationships spanning product, customer and location.
  • Enterprise-grade tooling. Global search across deeply nested nodes, relationship-based filtering, mass maintenance and restructuring, and an audit history for every structural change.

Versions, not overwrites

A reorganisation is not an edit. EBX® holds hierarchy versions side by side, so last year’s structure stays intact while next year’s is prepared and reviewed in a separate dataspace.

That makes a restructure something you can model, compare and approve before it reaches a single downstream report.

A move is never just one record

Reparenting a single node changes every total above it. That is why a structural change in EBX® is prepared in its own dataspace, where the proposed tree can be compared against the one in force and the effect on each roll-up seen before anyone approves it.

Validation rules travel with the structure, so a move that would orphan a member, create a cycle or break a mandatory level is refused at the point it is attempted rather than discovered in a quarter-end report.

One structure, every report

A roll-up is only trustworthy when finance, planning and analytics are all reading the same one. Once a structure is approved, EBX® delivers it to the applications, data platforms and reporting tools that consume it, carrying the version it belongs to — so any figure can be traced back to the structure that produced it.

“EBX® handles our complex financial and legal hierarchies natively, eliminating the need for expensive custom middleware.”

Data Architect
Enterprise Solutions, Global Financial Services

Hierarchy management: common questions

What is hierarchy management?
Hierarchy management is the practice of governing the structures that organise master data — which member rolls up into which, and under which view — as managed data rather than as a spreadsheet maintained alongside it. Learn more: What is hierarchy management?

What is an alternate hierarchy?
An alternate hierarchy is a second structure over the same members, used for a different purpose: a legal roll-up for statutory consolidation and a management roll-up for internal reporting, for example. Each is maintained and versioned separately, while the members underneath stay shared.

What is a ragged or skipped-level hierarchy?
One where a member has no parent at the level immediately above it — a store with no state recorded, in a country/state/city tree. Rather than dropping out of the structure, it attaches to the level above the gap, so the tree stays complete and totals stay correct.

Can the same data support more than one hierarchy?
Yes. Hierarchies in EBX® are views over governed records, not copies of them, so one set of cost centres, products or legal entities can carry as many structures as the business needs. A correction to a member is reflected in every structure it appears in.

Who maintains the structures?
The business owners do. Members are moved, attached and detached in the interface, with validation rules enforced as the change is made, and the change follows a review and approval path before it is published.

What happens to last year’s structure after a reorganisation?
It is kept. EBX holds hierarchy versions side by side, so a prior-period report can still be reproduced against the structure that was in force when it was first produced.

How does hierarchy management relate to reference data management?
Closely: many hierarchies are built from reference data such as cost centres, legal entities and industry classifications. See reference data management in EBX.

Bring order to your reference data

Talk to our team about your code lists, classifications and hierarchies, or explore how EBX® models, governs and shares master data, reference data and metadata in one platform.

Talk to ON EBX experts
/content/eds-onebx-com/contact-us
_self
Explore the EBX platform
/content/eds-onebx-com/platform
_self
_blank