Metadata in Oracle EPM is the structural configuration layer of an Essbase application — everything that defines the organisation of the data rather than the data itself. Metadata includes the dimension member hierarchies (which accounts exist, how they roll up), member properties (UDAs, data storage type, variance reporting direction), aliases (alternate member names in different alias tables, including Arabic), member formulas (the calculation expressions attached to specific members), substitution variables (runtime variables referenced in calculations and forms), and the application-level settings (currency, time period type, fiscal year start). Changing metadata changes the shape of the application; changing data changes the values within that shape. The distinction matters because metadata changes propagate immediately to all forms, rules, and reports that reference the affected members — a metadata change is not isolated to the specific area being modified.
How Metadata Is Managed
In Oracle EPM Cloud, metadata is managed through the application’s dimension editor in the Planning UI, through EPM Automate command-line operations, through the REST API, or through Data Management dimension import jobs. Oracle EDMCS (Enterprise Data Management Cloud Service) is Oracle’s dedicated metadata governance tool — it maintains the authoritative source of dimension member hierarchies and propagates approved changes to consuming EPM applications through a governed workflow. Without EDMCS or an equivalent governance process, metadata changes in production EPM applications are typically made directly in the Planning dimension editor by IT team members — a practice that produces inconsistent metadata states and difficult-to-audit change histories.
Metadata changes that add or remove members do not require database restructuring in ASO cubes — they take effect immediately after the dimension is refreshed. BSO cube metadata changes that affect the dense dimension structure require a database restructure, which writes all existing data to a new block structure — an operation that can take hours for large BSO databases and should be scheduled during off-hours maintenance windows, not performed during business hours.
Configuration and Design Considerations
Alias tables are a frequently underutilised metadata feature with specific relevance for GCC deployments. Each dimension member can have multiple aliases — one per alias table — allowing the same member to display in English in one report context and in Arabic in another, without maintaining separate dimension structures. Arabic aliases require UTF-8 encoding in the metadata import file and must use right-to-left character sequences; errors in encoding produce garbled Arabic display in Smart View and Planning forms rather than an error message, making them harder to detect.
What Goes Wrong in Practice
The most common metadata management failure in enterprise EPM environments is performing dimension member additions directly in the production application without a corresponding update to the shared services metadata import file that serves as the change record. After several years of this practice, the production application’s metadata diverges materially from any documented baseline — making impact assessment of proposed changes unreliable, migration to a new environment error-prone, and troubleshooting calculation issues dependent on individual team member knowledge rather than documented configuration. Every metadata change, however small, should be applied through a version-controlled import file, not through the UI editor, so that the import file remains the authoritative source of truth for the application’s structure.
How Loop Wise Solutions Handles This
We establish a metadata governance process at the start of every EPM engagement — defining the authoritative source for each dimension (typically an EDMCS viewpoint or a version-controlled flat file), the change control process for metadata modifications, and the import mechanism used to apply changes to the application. For clients without EDMCS, we maintain the governance through version-controlled import files stored in a shared repository, with a documented change log. We treat the import file as the production metadata record, not the application’s current state.
Answers before you ask.
Metadata is the structure — dimension members, hierarchies, aliases, member properties, and formula definitions — while data is the numeric values stored at member intersections. Metadata defines the shape of the model; data fills it. Loading a budget figure changes data; adding an account or moving a member in the hierarchy changes metadata.
Because everything references the structure. A single altered hierarchy, renamed member, or changed property can ripple through every form, business rule, report, and mapping that depends on it. Unlike a data load, a metadata change can silently break calculations or shift aggregations, so it demands testing in a non-production environment first.
Through Lifecycle Management or Data Integration dimension loads, so structural changes move from development to test to production in a controlled, repeatable way rather than being hand-edited in production. Treating metadata as version-controlled, migratable artefacts is what keeps environments aligned and changes auditable.
Consolidation and data storage operators, aliases, dimension and formula assignments, attribute associations, UDAs, and time-balance or variance-reporting settings, among others. These properties govern how a member aggregates, displays, and calculates. Because they control behaviour, an incorrect property is a metadata error that can distort results without any data being wrong.