Phase 1 — Design & Architecture
Decisions made here determine the structural foundation of the system. The dimension design and migration strategy you commit to now will still be running this implementation in 2031.
✓
P0 · Discovery
DECISION A
Application Creation — Irreversible Settings
Before a single dimension is built, you must commit to settings that cannot be changed once the application exists. Vision Corp has a Jan–Dec fiscal year, 6 currencies, and will require legal entity consolidation. Which settings do you enable on Day 1?
Part I L3Application SetupMulti-Currency
A. Enable: Monthly time period, Multi-Currency, Consolidation. Fiscal start: January. Lock all before clicking Create.
B. Enable: Quarterly time period (simpler), Multi-Currency, Consolidation. Upgrade to Monthly later if needed.
C. Enable: Monthly time period, Consolidation. Add Multi-Currency in Phase 2 once entities are confirmed.
D. Enable: Monthly time period, Multi-Currency. Skip Consolidation — use Groovy for currency rollups instead.
⚠ Discovery decision — irreversible after application creation. Wrong choices here require a full rebuild.
What do you verify before clicking Create — and what document do you produce before going live?
✓
P1 · Design & Architecture
DECISION B
Dense vs Sparse — Vision Corp Dimension Assignment
Vision has: Account (600 members), Period (25 members), Entity (12 members), Scenario (5 members), Version (3 members), Year (5 members). You must assign dense vs sparse before application creation. Tobias is waiting for your rationale.
Part IINODE sBlock Size
A. Dense: Account, Period. Sparse: Entity, Scenario, Version, Year
B. Dense: Account, Period, Scenario. Sparse: Entity, Version, Year
C. Dense: Account, Period, Entity. Sparse: Scenario, Version, Year
D. Dense: Account, Period, Version. Sparse: Entity, Scenario, Year
⚠ Design decision — irreversible. Requires a full database restructure to change post-creation.
Calculate the block size for your chosen assignment and justify it to Tobias:
✓
P1 · Design & Architecture
DECISION C
Forms 2.0 Migration Strategy
Vision has 50 classic forms from early testing. EPM 25.10 mandates Forms 2.0. Go-live is November 1st. You have 3 weeks. Design your migration sequence — Camille's input forms cannot break at go-live and the CFO Dashboard must be ready for Day 1.
Forms 2.0Part IV L11What's New 25.10
A. New forms first → simple input forms → complex composites after go-live. CFO Dashboard is new — build in 2.0 directly.
B. Migrate all 50 forms simultaneously in a single sprint — rip the band-aid before go-live.
C. Defer all migration — request an Oracle SR to keep Forms 1.0 for go-live stability.
D. Migrate only CFO Dashboard and executive views. Leave Camille's input forms on classic.
📋 Design decision — sequence locked before Build phase begins. Changes mid-Build disrupt testing.
Name the 5 forms you migrate first, the 5 you defer last, and the test you run before marking each migration complete:
✓
P2 · Build — Core Configuration
DECISION D
FY2026 Budget Block Creation & Seeding
It is October 15th. FY2025 Actuals are in the cube. FY2026 Budget blocks do not exist. Planners need a populated starting point by November 1st. Sione is watching — this is the decision that caused the block explosion at his last implementation.
NODE sDATACOPY@CREATEBLOCKHourglass
A. DATACOPY FY2025 Budget → FY2026 Budget, then Groovy growth factor rule
B. @CREATEBLOCK in a tightly scoped FIX (Budget, Working, FY2026, leaf entities only)
C. SET CREATENONMISSINGBLK ON across all entities, scenarios, and years
D. Planners seed manually — blocks created organically as they save form data
🔨 Build decision — reversible, but block explosion recovery costs a weekend. Get the FIX scope right.
Write the exact FIX scope for your chosen approach and explain what you do if Groovy still can't write to a block:
✓
P2 · Build — Core Configuration
DECISION E
CFO Dashboard — Forms 2.0 Apply Context Architecture
The CFO Dashboard has 8 grids and 4 charts — exactly at the 12-component limit. The CFO selects an entity and expects all 11 other components to update simultaneously. You are designing the Apply Context configuration.
Forms 2.0Apply ContextPart IV L1112-Component Limit
A. One dedicated 1-row master selector grid drives Apply Context to all 11 other components on Entity dimension
B. Configure Apply Context independently on each of the 8 grids — each manages its own Entity page
C. Use Navigation Flow parameters to pass Entity context — no Apply Context configuration needed
D. Hardcode Entity = Total_Vision — the CFO only ever looks at consolidated numbers
🔨 Build decision — Apply Context misconfiguration is the #1 Forms 2.0 support ticket in production.
Describe the master/detail configuration and the test that proves Grid B updates when the entity changes in the master:
✓
P3 · Build — Calculation & Automation
DECISION F
Headcount-Driven Cost Cascade — Engine Choice
Vision requires headcount-driven compensation (salary, benefits, payroll tax) to cascade automatically. 4,200 employees, 12 entities, 12 months. The WFP module feeds headcount. Finance wants to see the compensation update within 30 seconds of a planner changing headcount in the form.
Groovy Ch I & IIPart VLab 3Workforce Planning
A. Groovy beforeSave rule — calculates and batch-writes compensation on every form save
B. Dynamic Calc member formulas on Salary_Expense, Benefits_Expense, Payroll_Tax_Expense accounts
C. Nightly Essbase calc script in the master Business Rule Set — runs at 2am during budget cycle
D. Groovy action menu button — planners click "Calculate Compensation" after entering headcount
🔨 Automation decision — wrong engine means either slow forms (A without batching) or stale data (C with 2am delay).
Defend your choice against Dynamic Calc (Option B) specifically — when would B be correct, and why not here?
✓
P3 · Build — Calculation & Automation
DECISION G
Allocation Rule — Performance Crisis Response
The IT shared cost allocation Groovy rule runs 38 minutes. It calls getCell() 12 times and setCell() 12 times inside a loop. The nightly window is 45 minutes total. Go-live is in 4 days. You have one hour to fix this without rewriting the entire rule.
Groovy Ch IIHourglass PrincipleDataGridBuilderLab 3
A. Replace getCell() loop with DataGridBuilder pre-fetch; replace setCell() loop with one setDataCellValues() call
B. Move the allocation logic to an Essbase calc script — FIX(Budget, Working, FY2026)
C. Filter entities — only run the rule for entities where IT_Shared_Cost pool > $0
D. Split the rule into 4 parallel Groovy rules — one per entity group, run simultaneously
🔨 Automation decision — 38 minutes becomes <2 minutes with the right Hourglass levers. Identify them.
Name the specific Hourglass levers applied, estimate the time reduction, and explain why D (parallel execution) is dangerous:
✓
P4 · Integration
DECISION H
SAP Actuals Load — Reconciliation Control Design
SAP sends a nightly CSV. Nkechi needs a guarantee that what lands in EPBCS matches what left SAP — every morning, before Finance opens their dashboards. A previous implementation had $3.2M sitting in Unclassified_Actuals for 6 weeks undetected. Design the control.
Data IntegrationLab 5Part IIIEPM Automate
A. SAP_Control_Total account + Groovy reconciliation rule + EPM Automate abort on variance >$1,000
B. Manual Finance check each morning — a Finance analyst compares DI row count to SAP extract total
C. DI Workflow Validate step only — trust that DI's built-in validation catches all mapping errors
D. FRS report comparing Actuals YTD vs SAP year-to-date — Finance reviews weekly
🔌 Integration decision — no reconciliation control means silent failures. Nkechi will find it; the CFO shouldn't.
What is your materiality threshold for Vision Corp and what does the Finance Controller see the morning after a new unmapped GL code appears?
✓
P5 · Reporting & Dashboards
DECISION I
FR Studio Migration — Priority Sequence
25.06 de-supported Financial Reporting Studio. Vision has 22 legacy FR Studio reports used in the monthly close process. The CFO Board Pack, 6 variance reports, and 14 departmental P&L reports are all FR Studio. Go-live is November 1st. You have 5 weeks in P5.
What's New 25.06Part VIIOracle ReportsFRS
A. CFO Board Pack first → 6 variance reports → 14 departmental P&Ls. FR Studio reports remain as fallback.
B. Migrate all 22 simultaneously in Oracle Reports — FR Studio is de-supported so don't waste time on it.
C. Migrate 14 departmental P&Ls first — highest user count. Board Pack can wait until post go-live.
D. Leave all FR Studio reports running — de-supported doesn't mean broken. Migrate in Phase 2 post go-live.
📊 Reporting decision — Board Pack failure on go-live morning is the highest-visibility possible failure for Arjun.
Name one FR Studio feature Vision's reports use that you must verify is available in Oracle Reports before migration:
✓
P6 · Security & Workflow
DECISION J
Rolling Forecast — Locked Period Protection
Camille's rolling forecast advances monthly. January through CurPeriod−1 are actual months — planners must not be able to edit them. You need a mechanism that prevents edits to locked months without breaking the Forecast form for future months.
Part VIValid IntersectionsGroovy beforeSaveLab 2
A. Valid Intersections rule: Period ≤ CurPeriod−1 AND Scenario=Forecast → Invalid for Planner role
B. Groovy beforeSave guard — reads CurPeriod SubVar, checks edited cell's month index, cancels if locked
C. Form design — set column property Read Only for Actual period columns in the form definition
D. Trust Finance training — planners are told not to edit locked months in the user guide
🛡 Security decision — choose the mechanism that respects the Finance Admin bypass requirement.
When would you choose Valid Intersections (A) over Groovy (B), and how does a Finance Admin override the lock when actuals need correction?
✓
P7 · Testing — SIT & UAT
DECISION K
Approval Deadlock — UAT Discovery & Prevention
During UAT, the test team discovers that 3 entities are stuck Under Review because the test reviewer accounts were deleted. Budget cycle close is simulated for 48 hours from now. The UAT sign-off requires this resolved. What is your immediate action — and what system change does this expose?
Part VIApprovalsEPM AutomateLab 1
A. Service Admin promotes stuck entities via EPM Automate CLI, logs action, adds delegate accounts to PUH
B. Reset all entities to Not Started, recreate test accounts, restart UAT approval workflow from beginning
C. Temporarily assign Finance BP as Level 1 reviewer, promote, reassign original reviewer after UAT
D. Exclude the 3 stuck entities from the UAT sign-off — they're test accounts not production entities
🧪 Testing decision — UAT is the last safe place to discover this. Discovering it in production costs a budget cycle.
What Planning Unit Hierarchy configuration change do you add before UAT sign-off to prevent this in production?
✓
P8 · Go-Live & Stabilisation
DECISION L
Nightly Batch Architecture — Production Sequence
Day 1 of production. The nightly window is midnight to 5am. You must: load SAP actuals, run reconciliation, run master calc chain (headcount → allocation → validation), generate CFO Board Pack PDF, deliver to inboxes by 6am. One sequence failure aborts the rest.
EPM AutomateLab 4Lab 5Part VIII
A. SAP load → Reconciliation → Master calc chain → Report generation → Email (sequential, abort on failure)
B. SAP load → Calc chain runs in parallel with reconciliation → Report generation → Email
C. Master calc chain first (prior actuals) → SAP load → Reconciliation → Rerun calc → Report
D. SAP load → Immediate report generation → Reconciliation check → Email only if reconciliation passes
🚀 Go-Live decision — the batch sequence is your operational contract with Finance. Wrong order = wrong numbers in the Board Pack.
Write the first 5 EPM Automate commands in the shell script and the error handling line that alerts Finance Admin on failure:
✓
P8 · Go-Live & Stabilisation
DECISION M
EPM Automate Infrastructure — Java Runtime on Automation Server
Your Linux automation server runs EPM Automate for all nightly jobs. The 25.08 update requires Java 17. Your current server runs Java 8. Go-live is in 72 hours. The nightly batch runs every night including tonight.
What's New 25.08EPM AutomatePart VIII
A. Install Java 17 now, update JAVA_HOME, test EPM Automate login, run a test job before tonight's batch
B. Defer the upgrade to post go-live stabilisation — Java 8 still works, upgrade introduces risk right now
C. Move all automation to Windows server temporarily — EPM Automate Windows bundles its own Java
D. Contact Oracle Support — request an extension to keep Java 8 support for this environment
🚀 Go-Live decision — batch failures at go-live are the highest-impact visible failure. Verify the infrastructure before go-live.
Write the 3 shell commands you run to verify the Java upgrade is complete and EPM Automate is functional: