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.
