Dimension build in Oracle EPM is the process of automatically creating, updating, or restructuring Essbase dimension hierarchies by importing dimension member data from an external source — a delimited flat file, a database query through a JDBC connection, or a Data Management load rule — rather than manually adding, editing, or restructuring members through the Planning administration interface. Dimension build is the standard mechanism for maintaining dimension metadata in environments where the authoritative source for account hierarchies, entity structures, or cost centre codes is an ERP chart of accounts, Oracle EDMCS, or another master data management system. Manual maintenance of dimension hierarchies through the UI is practical only for small, stable dimensions; production-scale EPM environments with hundreds or thousands of members that change regularly require dimension build automation.
Dimension Build Mechanics
A dimension build process specifies the source of the dimension member data, a header record that maps source columns to Essbase dimension member properties (member name, parent member, consolidation operator, data storage type, UDA assignments, formula), and the build method. Three build methods are available: Parent-Child build (the source specifies each member’s parent, enabling Oracle to construct any hierarchy structure), Generation References (the source specifies the generation — level from the top — at which each member sits), and Level References (the source specifies the level — position from the leaf). Parent-Child is the most flexible and most commonly used; it does not require the source to know the hierarchy depth and handles arbitrary hierarchy structures.
In Oracle EPM Cloud, dimension build is typically executed through Data Integration’s dimension import feature or through EPM Automate’s importDimensionMetadata command. Both accept the dimension member file, apply the configured mapping, and push the result to the Planning application’s dimension editor.
Design Considerations
The dimension build process must handle member deletions carefully — Essbase does not allow deletion of a dimension member that contains data in any scenario, period, or version combination. The correct approach for deprecated members is to move them to an “Unallocated” or “Inactive” parent in the hierarchy rather than deleting them, until the data they contain has been cleared from the database or archived.
What Goes Wrong in Practice
The specific dimension build failure that most frequently produces unexpected application behaviour is a build that restructures the parent-child relationships of members referenced in business rules or member formulas. When a member is moved to a different parent — because the source ERP has reclassified a cost centre to a different division — any business rule that references the old parent will produce incorrect results on its next execution: it will calculate against the old parent’s members, excluding the moved cost centre. Business rules are not automatically updated when dimension structures change through dimension build; they must be reviewed and updated separately. Production dimension builds must be followed by a business rule impact analysis before the updated dimension is used in the next calculation cycle.
How Loop Wise Solutions Handles This
We maintain a cross-reference between dimension members and the business rules and member formulas that reference them. Every dimension build in a production environment is preceded by a check of this cross-reference — identifying any business rules or formulas that reference the members being restructured and scheduling their review and update before the dimension build is applied to the production application.
Answers before you ask.
It is the process of creating or updating Essbase dimension hierarchies from an external source — a flat file, database query, or Data Management load — rather than editing members by hand. It is used wherever the source of truth for hierarchies is a governed system like an ERP or EDMCS, so metadata stays synchronised with that source automatically.
A dimension build changes metadata — the members and hierarchy structure; a data load changes the numeric values stored against existing members. One reshapes the model, the other populates it. Running a data load for a member that a dimension build has not yet created will fail, which is why builds normally precede loads.
A build specification or mapping that tells Essbase how to interpret each source record — which field is the member name, its parent, alias, and properties — and whether to add, move, or update. Getting this mapping right is what keeps the resulting hierarchy valid; a mis-specified build can misplace members or corrupt the structure.
Because manual editing does not scale, drifts from the source of truth, and is error-prone across environments. Automated builds keep the application's hierarchies aligned with the governed master data, apply consistently, and can be scheduled. This is essential where dimensions change regularly and must match an ERP or EDMCS exactly.