Designing Planning Models: Versions, Data Actions, and Input Templates

Explanation

Once the foundational planning model exists, the next step in a real implementation is designing the operational mechanics that make planning usable at scale: multiple versions for scenario comparison, data actions for automated calculations and copies, and input templates that guide planners through a structured entry process. This lesson focuses on the intermediate configuration skills a consultant needs after the initial model is created. Version management in SAC Planning goes beyond the simple public/private distinction. In a mature implementation, you typically maintain several public versions such as Actual, Budget, Forecast_Q1, Forecast_Q2, representing different planning cycles or scenarios. Each planner may also work in private versions before publishing their numbers into a shared forecast version. Configuring this requires careful naming conventions and clear governance on who has write access to which version, controlled through the model's security and data access permissions combined with team/role assignments. Data Actions are the workhorse of SAC Planning logic. A Data Action is a sequence of steps (Copy, Advanced Formula using a scripting-like language, Allocation, or Link to another Data Action) that operates on planning model data in a controlled, repeatable way. A common pattern is a Copy step that copies Actual data from the prior year into a new Budget version as a starting point, followed by an Advanced Formula step that applies a growth percentage uplift, for example increasing all Cost Center expense lines by a stored growth driver value. Data Actions can be triggered manually by a planner through a button in a story, or scheduled to run automatically, which is valuable for month-end forecast rollovers. Advanced Formulas within Data Actions use a proprietary scripting syntax that supports variables, conditional logic (IF/ELSE), looping over dimension members, and referencing other models. A frequent intermediate-level task is writing a formula that calculates a derived measure, such as Gross Margin = Revenue - Cost, and ensuring the calculation respects the correct Version and Category context so it does not accidentally overwrite Actual data when running a Forecast calculation. Allocation is another critical mechanism, used when a top-level number (such as total corporate marketing budget) needs to be distributed down to lower-level dimension members (individual cost centers) based on a driver, such as headcount ratio or prior year spend ratio. Allocation steps within a Data Action define the source, target, and driver, and they must be tested carefully because incorrect driver selection leads to distorted downstream numbers that are hard to detect visually. Input templates are the story-level artifacts planners interact with directly. A well-designed input template typically uses a table with a fixed structure (Cost Center rows, Month columns) with input-enabled cells restricted to the current planning version and open Category. Story designers commonly add validation through Data Locking, which freezes cells or entire version/time combinations once a planning cycle closes, preventing accidental changes to submitted forecasts. Comments and value driver trees can be layered on top of input templates to help planners understand the business drivers behind numbers, though these are typically introduced in later, more advanced lessons. From a troubleshooting perspective, a common intermediate-level issue is a Data Action that appears to run successfully but produces zero or missing results; this is frequently caused by a mismatch between the Version/Category filter context used when triggering the action and the filter context expected by the formula steps inside the action. Consultants should always test Data Actions with a small, known dataset before running against the full model, and review execution logs available within SAC to identify which step failed or produced unexpected aggregation.

Code example

# Example Advanced Formula snippet inside a Data Action (SAC scripting syntax, illustrative)# Step: Apply 5% growth uplift to Budget version based on prior year Actual MEMBERSET [d/Version] = {"Budget_2025"}MEMBERSET [d/Category] = {"Budget"} [d/Version].[Budget_2025] =    [d/Version].[Actual_2024] * 1.05{    [d/Account].[Revenue],    [d/Account].[OperatingExpense]}

Real project scenario

During the annual budgeting cycle for a retail company, the FP&A team needs to seed the new Budget_2025 version with prior year Actuals plus a 5% inflation adjustment on operating expenses, then allow store managers to fine-tune numbers within their private versions before submitting. The consultant builds a Data Action combining a Copy step and an Advanced Formula uplift, and configures an input template with data locking that activates once each store manager submits their forecast, preventing later edits without FP&A approval.

Common mistakes

• Running a Data Action without first filtering to a test subset, causing unintended overwrites across the full model. • Writing Advanced Formulas without explicit Version/Category member restrictions, accidentally recalculating Actual data. • Using allocation drivers that reference stale or zero-value data, resulting in silent allocation failures where all values become zero. • Failing to apply data locking after a planning cycle closes, allowing accidental edits to finalized forecasts. • Designing input templates with too many unlocked dimensions, overwhelming planners and increasing the risk of data entry errors.

Best practices

• Always test Data Actions on a limited scope (single cost center or version) before executing broadly. • Explicitly scope Version and Category members within Advanced Formulas to avoid unintended overwrites. • Document allocation drivers and their data sources so business users can validate the logic. • Apply data locking immediately after each planning cycle milestone to protect submitted data. • Keep input templates focused on the minimum dimensions planners need to reduce entry errors and training time.

Interview angle

Candidates are often asked to describe the difference between a Copy step and an Advanced Formula step in a Data Action, and how they would troubleshoot a Data Action that produces zero results. Strong candidates explain checking the Version/Category context, reviewing execution logs, and testing incrementally, along with real examples of designing allocation logic for driver-based budget distribution.