Runtime prompts in Oracle EPM Planning are interactive input parameters presented to the user when a business rule is executed — appearing as a dialogue box before the rule runs and allowing the user to specify values that control the rule’s execution scope or behaviour. Instead of writing a separate business rule for each scenario, period, or entity set the calculation might need to operate on, a single business rule with runtime prompts can serve all variations: the user selects “Budget” or “Forecast” in a scenario prompt, “Q1 2026” in a period prompt, and the rule executes for the selected scope without any modification to the rule’s code. Runtime prompts are the parameterisation mechanism that makes planning business rules reusable — reducing the rule library size, simplifying maintenance, and providing users with control over calculation scope without requiring developer involvement for each variation.
Runtime Prompt Types
| Prompt Type | Input Format | Rule Reference | Use Case |
|---|---|---|---|
| Member selector | User selects one or more members from a specified dimension | &VariableName in FIX statement | Select the entity or cost centre to run a spread calculation for |
| Substitution variable | Displays a substitution variable’s current value; user can override | &CurYear, &CurPeriod | Default to current year but allow user to select prior year for historical recalculation |
| String | Free-text input from the user | &TextInput | Provide a comment or reference code logged during rule execution |
| Number | Numeric input from the user | &Rate in calculation formula | Apply a user-specified growth rate or cost rate without hardcoding in the rule |
| Date | Date selector | &StartDate | Specify the effective date for a headcount change or a planning assumption |
Runtime Prompts in Groovy and Calc Script
Runtime prompt values are passed into Essbase Calc Scripts and Groovy scripts through the substitution variable mechanism. In a Calc Script, FIX(&ScenarioPrompt, &PeriodPrompt) uses the user’s selections to restrict the calculation scope to the specified scenario and period. In a Groovy script, runtime prompt values are accessed through the operation’s execution context and can be used in conditional logic — for example, varying the calculation logic based on whether the user selected “Budget” or “Rolling Forecast” in the scenario prompt. The combination of Groovy’s conditional capability and runtime prompts enables sophisticated parameterised business rules that adapt their behaviour based on user input at execution time.
Runtime Prompt Design Principles
Two principles govern effective runtime prompt design. First, prompt scope should be the minimum that users need control over — every prompt adds friction (a user must make a selection before the rule runs) and risk (a user who selects the wrong scope can accidentally overwrite data in the wrong period or entity). Prompts are appropriate for scope that genuinely varies by execution; for scope that is always the same (current period calculation, current scenario), substitution variables managed by the EPM administrator are more appropriate than user-facing prompts. Second, prompt defaults should be the most common correct value — if 95% of rule executions should operate on the current period, the period prompt should default to the current period substitution variable value, requiring the user to actively change it only for the 5% of executions where a different period is appropriate.
What Goes Wrong in Practice
The most damaging runtime prompt failure in production EPM environments is a business rule with a runtime prompt that allows a user to select a scope broader than the rule was designed for — selecting all entities rather than a single entity, or selecting all scenarios rather than the current working scenario — and accidentally executing a calculation across the entire database. A CLEARDATA rule with a scope prompt that allows “All Entities” and “All Scenarios” can, if a user selects those values accidentally, clear all data from the application. Runtime prompts for potentially destructive operations should have restricted member selectors — limiting the selectable range to safe subsets of the dimension — rather than open member selectors that allow selection of the entire dimension.
How Loop Wise Solutions Designs Runtime Prompts
We design runtime prompts with explicitly defined member selector restrictions — each prompt has a defined selectable range that prevents the user from specifying a scope beyond what the rule was designed to handle. Prompts for rules that clear or overwrite data have the narrowest possible selectable ranges and include a confirmation warning in the rule’s launch dialogue.
