Oracle Fusion REST API: Organization and Department Hierarchy (Why organizationTreeNodesLOV Doesn't Have It)

Three separate Cloud Customer Connect threads ask the same question in different words: how do you get the organization or department hierarchy — the actual parent-child tree, not just a flat list — out of the Oracle Fusion HCM REST API? One asker explicitly ruled out HR_ORGANIZATION_UNITS, HR_ORGANIZATION_INFORMATION, and HR_ALL_ORGANIZATION_UNITS before asking. None of the threads have a working REST answer. Here’s why the endpoint everyone reaches for doesn’t have it, where the hierarchy actually lives in Oracle’s schema, and what’s confirmed to work today.

The trap: organizationTreeNodesLOV looks like it should work

The name says “tree.” The resource is under /hcmRestApi/. It’s a reasonable first guess. Querying it against OPAL’s own bundled catalog shows exactly what it returns:

{
  "OrganizationId": 300000012345678,
  "OrganizationName": "US Sales Division",
  "EffectiveStartDate": "2001-01-01",
  "EffectiveEndDate": "4712-12-31"
}

That’s it — the complete field list. No ParentOrganizationId, no ParentId, nothing that tells you what this organization’s parent or children are. It’s a flat list-of-values resource, built for populating a picklist in the UI, not for walking a tree.

The same is true of its two siblings, checked the same way against the real spec:

• departmentTreeNodesLOV returns DepartmentName, OrganizationId, EffectiveStartDate, EffectiveEndDate — no parent field.
• positionTreeNodesLOV returns PositionId, PositionName, EffectiveStartDate, EffectiveEndDate — no parent field.

Three different LOV endpoints, three different flat lists, zero hierarchy between them. This is the exact wall three real developers hit:

• “How to get the departments hierarchy in hcmRestApi REST API” — “I was unable to locate any mapping field for the parent and child relationship.”
• “REST API to get the organization tree hierarchy” — “Is there any REST API available for this or this can only be done through BIP/Extract?”
• “Fusion HCM Organization tree API does not reflect relationships” — the most detailed of the three, describing a 5-level org hierarchy visible in the HCM UI that’s invisible through every REST resource tried.
• An Oracle Forums thread asking the same question has sat with zero replies.

Where the hierarchy actually lives

Department, organization, and position hierarchies in Oracle Fusion HCM aren’t stored as a parent field on the organization record — they’re stored as trees, a generic hierarchy framework shared across Fusion Applications (the same mechanism Financials uses for GL account hierarchies and cost-center rollups). Oracle’s own HCM documentation confirms four supported tree types: “department, organization, position, and geography.” (HCM Trees, docs.oracle.com)

Each tree type has its own TreeStructureCode, confirmed directly from Oracle’s data-loading guidelines:

• Department trees — TreeStructureCode must be PER_DEPT_TREE_STRUCTURE. “The TreeStructureCode attribute of both the department tree and the department tree version must be set to PER_DEPT_TREE_STRUCTURE for a department tree.” (Guidelines for Loading Department Trees)
• Organization trees — TreeStructureCode must be PER_ORG_TREE_STRUCTURE. (Guidelines for Loading Organization Tree Nodes)

These aren’t the same tree described two ways — Oracle scopes them differently. A department tree can only contain departments; an organization tree can mix departments, divisions, legal employers, and other organization types, and is used for broader security and roll-up analysis.

The underlying table confirms the connection to the shared tree schema: PER_DEPT_TREE_NODE_RF’s TREE_STRUCTURE_CODE column is documented as a “Foreign key to TREE_STRUCTURE_CODE on FND_TREE” — HCM’s tree data is registered inside Oracle’s common FND_TREE infrastructure, the same infrastructure Financials trees use. (PerDeptTreeNodeRf table reference)

The one REST resource confirmed to read tree data: fndTreeNodes

Oracle’s Common Features REST API exposes tree nodes through fndTreeNodes — and in OPAL’s own ingested catalog, it appears only under the FSCM module surface, at /fscmRestApi/resources/{version}/fndTreeNodes, with 34 real query (q) fields including TreeStructureCode, TreeCode, ParentPk1Value, ParentPk2Value, Pk1Value, Pk1StartValue, Pk1EndValue, and TreeVersionId. It does not appear anywhere in the HCM module’s spec.

This endpoint is real and confirmed working — for GL account hierarchies, not HCM. Multiple independent sources show the same working pattern:

GET /fscmRestApi/resources/11.13.18.05/fndTreeNodes?q=TreeStructureCode=GL_ACCT_FLEX;TreeCode=XXX_GL_Account_Setup_Tree;ParentPk1Value=XX_Parent

A Cloud Customer Connect user successfully used this exact shape to walk down to level 3 of an account hierarchy before asking how to reach level 4 — confirming the pattern works, at least for Financials trees. (discussion/876006)

The honest gap: does this work for HCM trees too?

Architecturally, it should. PER_DEPT_TREE_STRUCTURE and PER_ORG_TREE_STRUCTURE are registered in the same shared FND_TREE schema that fndTreeNodes reads from for GL trees. The theory is straightforward: swap TreeStructureCode=GL_ACCT_FLEX for TreeStructureCode=PER_DEPT_TREE_STRUCTURE (or PER_ORG_TREE_STRUCTURE), supply your real TreeCode, and query the FSCM-hosted fndTreeNodes endpoint even though you’re after HCM data.

We could not find a single public example of anyone actually doing this and getting HCM hierarchy data back. No Cloud Customer Connect thread, blog post, or forum answer shows a working fndTreeNodes call with an HCM TreeStructureCode. The three threads above — all from developers who clearly would have tried this if they’d found it — went unanswered instead. That absence is itself informative: either nobody has published it, or it doesn’t actually work cross-module the way the shared-schema architecture suggests it should. We’re not going to assert it works without evidence either way — if you try it against your own instance, the query shape to test is:

GET /fscmRestApi/resources/11.13.18.05/fndTreeNodes?q=TreeStructureCode=PER_DEPT_TREE_STRUCTURE;TreeCode=<your department tree code>

If that returns real department-tree rows with populated ParentPk1Value/Pk1Value fields for your instance, you’ve got a working REST path to HCM hierarchy that isn’t documented anywhere else — worth confirming against your own tree codes (GET /hcmRestApi/resources/{version}/departmentTrees or your HCM configuration will show the real TreeCode value for your instance) before relying on it.

What’s confirmed to work today

Until that’s verified, the two paths that are actually confirmed by real practitioners:

• BI Publisher (BIP) extracts. Several of the unanswered CCC threads explicitly point toward BIP as the fallback once REST comes up empty — a subject area or data model built against the tree tables can return full parent-child rows directly.
• Direct SQL / OTBI against the tree-node tables. A consultant’s published extraction walkthrough queries PER_ORG_TREE_NODE_RF directly with tree_structure_code = 'PER_ORG_TREE_STRUCTURE' and a specific tree_code, joining node rows to reconstruct the parent-child structure. (Oracle HCM Organization Hierarchy Extraction) This requires OTBI/database-level access, not a REST call, but it’s a proven, working method.

Neither is a REST endpoint you can call from an integration the way you’d call /workers or /absences — which is the real, unresolved gap behind all three community threads. If Oracle ever documents a supported REST path for HCM tree hierarchy, or if you confirm the fndTreeNodes cross-module theory works against a real instance, that’s the piece that would close this out properly.

Where this fits with everything else

Organization and department data shows up constantly in worker records — see the workers endpoint guide for the flat organization/department fields that are available per-worker, and the Oracle HCM REST API examples post for q-filtering on those fields directly. For the general mechanics of finder-based lookups (a different pattern from tree traversal), see the finders guide. For the full request lifecycle — auth, q, pagination — see the Oracle HCM API guide and the endpoint catalog.

---

This post is part of our complete Oracle HCM API guide — auth, base URLs, q filters, finders, and key endpoints in one place.