Ask an AI assistant how to sync governed EPM hierarchies into Databricks and you will get a very good answer for a data engineer: export from the EPM application, land files in cloud storage, stream them into a bronze Delta table, normalize parent-child edges in silver, flatten for reporting in gold, register everything in Unity Catalog, and write a MERGE statement to handle changes. All of that works. It is also the wrong place to start if you are the person who owns the hierarchies.
Financial system administrators do not have a Databricks ingestion problem. They have a governance problem that happens to end in Databricks. The account, entity, cost center, and product hierarchies that the lakehouse needs are the same hierarchies that drive consolidation, planning, and reporting. They already have owners, approval workflows, and audit requirements. The question these teams are actually asking is simpler and harder: how do I get the hierarchy I already govern into Databricks without governing it a second time?
This guide answers that question the way EPM and finance systems teams prefer it answered. It covers what "governed" has to mean once a hierarchy leaves the EPM application, why the build-it-yourself pipeline quietly creates a second system of record, and the pattern Oracle EPM and OneStream customers use to publish one approved hierarchy to every system that needs it. EPMware, which appears in that pattern, is our product and includes a Databricks adapter built for exactly this. We say so up front so you can weigh the recommendation accordingly.
A hierarchy export is not a governed hierarchy. The difference is everything that made the hierarchy trustworthy inside the EPM application: the request that introduced a new cost center, the approval that let it through, the validation that confirmed it rolled up correctly, and the record of who did all of that and when. A governed sync has to carry that context with the structure, or Databricks ends up with a copy that looks right and cannot be defended.
In practice, a governed hierarchy in Databricks needs five things the raw structure does not give you on its own:
Every pattern that follows should be judged on whether it delivers those five things, and on how much of each it forces you to rebuild in Databricks.
The standard advice looks like this. Export the hierarchy from every EPM application, land a CSV and a manifest in S3 or ADLS, ingest with Auto Loader into a bronze table, normalize into node and edge tables in silver, build flattened and closure tables in gold, register the schema in Unity Catalog, and run validation checks for cycles, orphans, and duplicate roots before promoting a new version to current.
To be fair, this pattern is well engineered, and for a team with strong data engineering capacity it produces a clean, well-governed copy in Databricks. The validation checks are sensible. Keeping bronze immutable is right. Versioned snapshots instead of nightly overwrites is exactly the correct instinct.
The problem is what it does to governance. Look at where the real controls end up living:
The pipeline is not the system of record, but it behaves like one. That is how a finance team ends up with a hierarchy in Databricks that technically came from EPM and still does not match the board deck. If your data warehouse numbers already disagree with your EPM numbers, this is usually why.
The export pipeline rebuilds governance inside the lakehouse. The governed hub publishes one approved version to every subscriber, Databricks included.
The teams that avoid that outcome invert the architecture. Instead of extracting from the EPM application and governing the copy, they govern once in a hub that sits upstream of every consumer, and they treat Databricks as one more subscriber alongside the EPM applications themselves.
In that model, a single change request, say a new entity for an acquisition, moves through one workflow: requested by finance, enriched with properties, validated against the rules for every target system at once, approved by the right owners, and then deployed to all subscribers in the same step. Oracle PBCS and FCCS receive it. OneStream receives it. Databricks receives it. Power BI reads it from Databricks. There is one version number, one approval record, and one audit trail, because there was only ever one change.
This is what Oracle EPM and OneStream customers mean when they ask for governed sync. They are not asking for a better pipeline. They are asking for the hierarchy in Databricks to be the same governed object that is in their EPM application, with the same history, so that nobody has to reconcile the two.
Oracle EPM Cloud teams usually arrive at this problem from one of two places. Either they are running native dimension maintenance in PBCS and FCCS and have no governed hierarchy to export in the first place, or they have Oracle EDM and are considering using its REST API or EPM Automate to push viewpoint exports into a landing zone. The export route works, but it adds a metered, scheduled job to a tool whose record-based pricing already discourages registering more of your metadata, and it still leaves validation and approval to be rebuilt on the Databricks side.
The hub model solves both cases. Hierarchies are governed in EPMware, deployed to PBCS, FCCS, TRCS, or PCMCS through prebuilt adapters, and published to Databricks through the Databricks adapter from the same approved version. The Oracle EPM applications and the lakehouse are never out of step because they were never updated separately. Teams that still run on-premises Hyperion get the same result: HFM, Essbase, and Planning subscribe to the same hub.
OneStream teams tend to ask a sharper question: OneStream already has Application Control Manager, so why would hierarchies for Databricks come from anywhere else? The answer is scope. ACM governs change inside OneStream well. It does not reach the ERP that originates most account and entity changes, and it does not publish to the lakehouse. The moment Databricks needs the OneStream entity structure, somebody has to extract it, and that extract is where governance breaks.
EPMware can also work alongside ACM rather than replacing it. The ERP-originated change is governed once, deployed into OneStream, and published to Databricks from the same approved version, with the full request and approval record behind it. OneStream stays the consolidation engine. Databricks gets a hierarchy that matches it exactly.
EPMware's Databricks adapter publishes validated, approved, fully auditable hierarchies and dimensions from the EPMware hub directly into Databricks. Because it is a deployment target inside EPMware's workflow rather than a separate extraction job, it inherits every control that already protects your EPM applications. In practice the sequence is:
Illustration: a governed entity hierarchy in Databricks Catalog Explorer, with lineage back to the EPMware request that created it.
Hierarchy restructuring, which is where export-based pipelines usually fail, is handled natively. Reclassifying accounts, reorganizing cost centers, or rebuilding product rollups are governed changes like any other, validated and approved before they land in Databricks, with the previous structure preserved.
Whichever pattern you use, the tables Databricks consumers see should carry the governance, not just the shape. Use this as a checklist when you review what lands in your lakehouse. If any column is missing, you have an export, not a governed hierarchy.
A governed hierarchy table carries identity, structure, properties, version, and governance columns. Without the last two, it is an export.
| Column group | What it carries | Why it matters |
|---|---|---|
| Identity | Immutable member key, name, alias, description | Joins survive renames |
| Structure | Hierarchy name, parent key, child key, sort order, relationship type | Rebuilds every rollup, including alternates |
| Properties | Account type, rollup operator, currency, consolidation and custom attributes | Preserves business meaning in the lakehouse |
| Version | Approved version, effective from, effective to, current flag | Point-in-time reporting and reproducible closes |
| Governance | Request ID, requested by, approved by, deployed at | Audit evidence without a separate project |
Register the published tables in Unity Catalog and grant access to groups, not individuals. That is where Databricks governance adds real value: controlling who can read the hierarchy and tracing what consumes it. What Unity Catalog should not do is become the place where the hierarchy itself is edited. The system of record stays upstream.
Most of the pain finance teams attribute to Databricks actually surfaces in Power BI. A report built on lakehouse tables shows one revenue total, the consolidation system shows another, and the board meeting turns into a reconciliation meeting. The cause is almost always that the hierarchy feeding Databricks and the hierarchy feeding EPM were maintained separately and drifted.
When Databricks subscribes to the same governed version as the EPM application, Power BI inherits the fix for free. Build Power BI's dimension tables from the governed hierarchy tables in Databricks, join facts to the immutable member key, and never embed a hand-maintained hierarchy in a Power BI model again. The numbers match because the structures behind them are identical.
Not if the hierarchy is governed upstream. With EPMware's Databricks adapter, Databricks is a deployment target in the same workflow that deploys to Oracle EPM and OneStream, so there is no separate export, landing zone, or notebook to maintain. Teams without a governance hub do need to build and maintain the bronze, silver, and gold pipeline, including validation and versioning.
No. Unity Catalog should govern access to and lineage of the published hierarchy, which it does well. The hierarchy itself should be mastered where finance owns it and where approval and validation already run. Making Databricks the authority creates a second system of record and reintroduces the reconciliation problem.
Either by exporting from Oracle EDM through its REST API or EPM Automate into a landing zone and building a pipeline, or by governing the hierarchy in a hub such as EPMware that deploys to PBCS and FCCS and publishes to Databricks from the same approved version. The second route avoids a second governance layer and does not depend on EDM's record-metered pricing.
Yes. EPMware works alongside OneStream ACM. ERP-originated changes are governed once, deployed into OneStream, and published to Databricks from the same approved version. ACM continues to control change inside OneStream.
Every published version carries an approved version identifier and effective dates. Query the version that was current on the close date rather than the latest structure. If your current sync overwrites a table nightly without versioning, that question cannot be answered, which is the first thing to fix.
The fastest way to evaluate any of this is with your own entity and account structures. Bring the hierarchy that your Databricks and Power BI numbers currently disagree on, and we will show you what it looks like governed once and published to Oracle EPM or OneStream and Databricks in the same step. Schedule a demo with EPMware, or read the Databricks adapter announcement for the background.