In Oracle EPM Cloud, a sandbox is a private working space within the planning application that belongs to an individual user. Changes made inside the sandbox — updated assumptions, modified forecasts, experimental scenarios — are visible only to the sandbox owner and do not affect the shared production data until the user explicitly promotes the sandbox contents to the main application. Think of it as a personal scratchpad within the planning system: the planner can explore the impact of different assumptions without disrupting the budget cycle for everyone else.
Why Sandboxes Matter in a Collaborative Planning Environment
In a large EPM deployment with dozens or hundreds of concurrent planners — typical in a GCC group with multiple subsidiaries participating in the same planning cycle — uncontrolled changes to shared data create coordination problems. If a budget manager in the UAE changes a salary assumption to model a hiring scenario, and that change immediately affects what the Saudi finance director sees in the consolidated view, the planning process becomes unreliable. Sandboxes solve this by keeping experimental changes isolated until they are ready to be committed.
For senior finance leaders reviewing draft budgets from multiple business units, sandboxes also support the review process. A finance director can create a sandbox containing proposed adjustments to a business unit’s submission, model the group-level implications of those adjustments, and share the sandbox outputs for discussion before any changes are committed to the approved plan.
What Good Sandbox Governance Looks Like
The key governance question is when sandboxes are promoted to the main application and by whom. In a well-governed planning cycle, individual planners use sandboxes for working assumptions during the budget build, promote their input to the main application when their section of the plan is ready for review, and the review and approval workflow then controls what enters the approved version. Without this discipline, sandboxes accumulate outdated scenarios that never get cleaned up, and users lose track of which version of their assumptions is actually reflected in the plan.
Where Sandbox Usage Goes Wrong
The most common problem is users who treat the sandbox as their primary working environment and rarely promote to the main application, leading to situations where the consolidated plan does not reflect the most current assumptions held by each business unit. The finance team discovers this mismatch during the budget review when the numbers on the consolidated report do not match what individual planners believe they submitted. Sandbox discipline — a clear process for when users are expected to promote and lock their inputs — is a people and process issue, not a technology one, and it needs to be established as part of the planning cycle governance, not assumed as a user behaviour.
How Loop Wise Solutions Handles This
We include sandbox governance in every planning cycle design we produce — defining who can create sandboxes, when inputs must be promoted to the main application, and what happens to sandboxes that contain data not yet promoted at the close of the submission window. These are decisions that need to be made before the planning application goes live, not resolved reactively when the first budget cycle runs into coordination problems.
Answers before you ask.
Planning involves testing assumptions that should not touch shared, approved data. A sandbox gives each planner a private working copy where they can model what-if scenarios freely, then keep or discard the results. Without it, experimentation risks overwriting numbers other people depend on, so the sandbox is what makes safe exploration possible during a live planning cycle.
Sandbox changes are isolated to that planner's view until they deliberately publish them to the shared model. Until then, other users see the unchanged production data. This separation means a planner can run a dozen scenarios without anyone else's reports moving, and only committed results become visible to the wider team.
A sandbox is a private, temporary workspace for experimentation; scenarios and versions are structured, shared dimensions of the plan — such as budget versus forecast, or draft versus approved — that everyone can see. You experiment in a sandbox, then commit the result into a proper scenario or version. Confusing the two leads to uncontrolled data.
The main risk is treating a sandbox as permanent storage — leaving important assumptions in a private space where colleagues cannot see or govern them. Work that matters should be published into the shared, controlled model. Used well, the sandbox speeds analysis; used poorly, it becomes another silo of ungoverned numbers.
No. It is designed for planners and analysts to use directly as part of normal what-if work, not for administrators. The point is to let finance people experiment safely without raising a change request or risking shared data. The discipline required is procedural — remembering to publish what should be kept — rather than technical.