A data form in Oracle EPM is a structured grid — defined in Planning and rendered in both the Planning web interface and in Smart View — that presents specific data intersections for user input and review. Each form specifies which dimension members appear on rows, which on columns, which on page drop-downs, and which are fixed in the form’s point of view (POV). A form is not a report — it does not retrieve arbitrary data from the Essbase cube on demand; it displays the specific intersections defined in its layout, and users enter or review data at those intersections.
How Forms Work Technically
When a user opens a form, Planning generates an Essbase MDX retrieval query based on the form’s row, column, and page definitions, retrieves the data for the intersections in scope, and renders the result in the grid. The query scope — the number of member intersections that must be retrieved — directly determines form load time. A form with 500 row members, 24 column members (months), and an entity page selector produces 12,000 data retrievals per entity. If each entity is loaded separately, the form loads in seconds; if all entities are loaded simultaneously into a single form through cross-dimensional row definitions, the retrieval load scales proportionally and form performance degrades.
Form business rules are associated with Planning forms — a rule configured as a “Save” rule triggers automatically when the user saves data to a form; a rule configured as a “Launch” button provides user-triggered calculation access from within the form interface. This association is managed in the form’s business rule configuration and determines the calculation workflow the user experiences when interacting with the form.
Configuration and Design Considerations
The performance-critical design parameter in forms is the number of retrievable intersections — the product of the row member count, column member count, and page dimension combinations. Forms with more than a few thousand retrievable intersections load slowly. The solution is to decompose large forms into smaller, focused forms that retrieve a subset of the data at a time. Users navigate between focused forms rather than using a single large form that attempts to show everything simultaneously.
What Goes Wrong in Practice
The specific form design failure that most consistently produces poor EPM user adoption is designing forms that mirror the underlying Essbase dimension hierarchy rather than the finance user’s workflow. A form that presents accounts in the order they appear in the dimension hierarchy — with natural account codes as row labels rather than descriptive management account names — is navigable by the EPM architect who knows the account structure but not by the finance manager who thinks in terms of “Headcount Costs” and “Technology Costs.” Forms must be designed for the finance user’s mental model of the data, using alias names that reflect management account descriptions, with members in the sequence that matches the user’s planning workflow — not the sequence that reflects the dimension’s technical structure.
How Loop Wise Solutions Handles This
We prototype form layouts with the finance team before technical form construction begins — presenting wireframe form designs in Excel or paper format, validating the account groupings, labels, and column layouts with the actual users before any form is built in the Planning application. Form design sign-off by the user community before build is non-negotiable in our delivery process; forms built without user validation are the most common cause of late-stage rework in EPM implementations.
