A planning unit in Oracle EPM is the atomic unit of the planning workflow — defined as the intersection of a specific entity (or entity group) and a specific scenario/version combination that is tracked as a discrete work item through the approval process. Each planning unit has an independent approval status (Not Started, First Pass, Under Review, Approved, Published, Locked), an action history log showing every status change and comment, and a designated owner responsible for its current state. Planning units are the mechanism through which Oracle Planning translates “the budget for Entity X in the FY25 Budget scenario” into a tracked, auditable workflow object that moves through defined approval stages.
Planning Unit Hierarchies
Planning units are organised through a Planning Unit Hierarchy (PUH) — a configuration that maps entities in the application’s entity dimension to approval process roles. The PUH defines which entities are managed as separate planning units, which entities are grouped into parent planning units that aggregate their children, and which Planning users and groups own each level of the hierarchy. The PUH is separate from the Essbase entity dimension hierarchy — a planning unit hierarchy can group entities differently from the consolidation hierarchy, allowing regional budget managers to own planning units spanning multiple legal entities.
The planning unit’s status determines what operations are available for the data it covers. A Locked planning unit cannot receive data submissions — forms that map to a locked planning unit are read-only. The approval workflow enforces both data review discipline and data access control — a planning unit’s status determines whether data can be written, reviewed, or only read at each stage. Smart View’s “locked cells” behaviour is frequently caused by the planning unit being in a status that restricts write-back, not by a form configuration setting.
Design Considerations
Planning unit hierarchy design must align with the organisation’s actual budget governance structure. A PUH with hundreds of individual planning units provides granular tracking but creates significant administrative overhead; a PUH with a small number of aggregated planning units is easier to manage but provides less visibility into which specific entities have completed their submissions. The design must reflect the actual review governance, not an ideal that the organisation does not have the capacity to operate.
What Goes Wrong in Practice
The specific planning unit failure that most frequently causes data accessibility problems during the budget cycle is an entity assigned to a planning unit whose parent is Locked — locking all child planning units even when only the parent was intended to be locked. Oracle’s planning unit propagation behaviour cascades lock status from parent to child planning units when a parent is locked; this is the intended behaviour, but it surprises implementations that lock a parent to signal completion without intending to restrict write-back for the child entities. The entity finance teams discover they cannot enter data in their planning forms without any indication of which parent planning unit’s lock is causing the restriction.
How Loop Wise Solutions Handles This
We document the planning unit hierarchy design alongside the budget workflow, explicitly mapping each PUH level to the budget governance stage it represents and documenting the status propagation behaviour for each transition. We include planning unit status transitions in the user training — ensuring that budget workflow owners understand which status changes cascade to child planning units before they initiate any status change in the production application.
