Forecasts and Custom Planning Solutions
A budget is a starting point — not the end of the planning cycle. Once the annual budget is approved, the FP&A team shifts to maintaining a rolling forecast that blends actual results with forward-looking projections. Beyond the core P&L, many organizations also need specialty planning modules for headcount, capital projects, or other detailed processes. This guide covers rolling forecasts, variance analysis, and the patterns for building custom CRUD-based planning solutions in OneStream.
From Budget to Forecast
A budget is a fixed plan — set once at the start of the year and locked. A forecast is a living document that updates as the year progresses. The key differences:
- Time horizon — Budgets cover a fixed period (calendar year). Forecasts update monthly or quarterly — either covering the remaining fiscal year (YTG) or a fixed rolling window (12 or 18 months).
- Update frequency — Budgets are built once (with possible revisions). Forecasts are updated every cycle as new actuals become available.
- Scenario architecture — The team works in a single Forecast_Working scenario each cycle. Actuals are seeded for closed months, and projections are entered or recalculated for open months. When the cycle is approved, Forecast_Working is copied to a monthly snapshot — Forecast_M1 through Forecast_M12 — preserving the complete picture of each cycle for trend and accuracy analysis.
In OneStream, Forecast_Working and each Forecast_MX snapshot are configured as separate Scenario Types. Forecast_Working is the editable workspace; the snapshots use
NoInputPeriods to lock the actual-seeded months from user editing (e.g., Forecast_M3 has NoInputPeriods = 2, preventing changes to January and February). Setting Workflow Tracking Frequency to "All Time Periods" on each snapshot allows the same scenario to be reused across fiscal years.For ABC Manufacturing, Forecast_Working as of the June cycle contains:
- January – May: Actual data (seeded from the Actual scenario)
- June – December: Forecast data (projected by the FP&A team)
When the June cycle is approved, Forecast_Working is saved to Forecast_M6. This means ABC can later compare Forecast_M3 (what the team projected in March) against Forecast_M6 (what they projected in June) to measure forecast accuracy and track trend shifts.
The Forecast Cycle
Each forecast cycle is a three-phase process: seed, calculate, and publish. A Finance Business Rule handles the first two phases in Forecast_Working, and a separate step copies the result to the monthly snapshot.
Phase 1: Seed Forecast_Working
Copy actuals for closed months into Forecast_Working. The rule uses
lastClosedPeriod to determine the cutoff — the same period-number pattern from the budget seeding guide, but writing to S#Forecast_Working.Phase 2: Calculate Open Months
Run the same driver-based calculations as the budget for the open months in Forecast_Working. The calculation logic for open months mirrors the budget calculation from the previous guide — many implementations share calculation logic between Budget and Forecast scenarios by extracting shared helper methods or parameterizing the same rule to work for both.
Phase 3: Publish Snapshot
Once the forecast cycle is approved, copy Forecast_Working to the corresponding monthly snapshot. For a March cycle, this publishes to Forecast_M3:
This publish step is typically run as a Data Management step or triggered by a Workflow event after the forecast is approved — not embedded in the Finance Business Rule that handles seeding and calculation.
Isolating Phases with CustomCalculate
The Calculate approach shown above runs inside the DUCS — it fires on every calculation and consolidation pass. For production forecast workflows, split each phase into a separate CustomCalculate function so the FP&A team has granular, on-demand control: seed without recalculating, recalculate without republishing.
Each function maps to its own Custom Calculate Data Management step. The step's Business Rule property points to the Finance BR; the Function Name property is set to
SeedForecast, CalcForecast, or PublishForecast. The three steps can run in a sequence (seed → calculate → publish) or independently — for example, running just CalcForecast after updating driver assumptions without re-seeding actuals.Each Custom Calculate function can also be triggered from a Dashboard Parameter Component server task action. The arguments follow the format
{BusinessRuleName},{FunctionName},{NameValuePairs} — for example, a "Seed Actuals" button with arguments {ForecastCalc},{SeedForecast},{}. A forecast management dashboard can present one button per phase, giving the FP&A team point-and-click control over the entire cycle.Variance Reporting
Variance analysis — comparing Budget vs. Actual or Forecast vs. Actual — is one of the primary outputs of any FP&A process. OneStream supports variance reporting through both calculated cube data and dashboard components.
The simplest approach is calculating variance accounts directly in the cube:
Dashboards then present variance data using conditional formatting (red/green for unfavorable/favorable), waterfall charts, and drill-down navigation that lets the CFO click from the company total down to a specific entity, department, and account to understand the root cause of a variance.
Specialty Planning: Headcount
The core P&L budget uses aggregate driver accounts — FTE and AvgSalary at the department level. But many organizations need employee-level detail: individual names, exact salaries, start/end dates, benefit elections, and department transfers. This exceeds what the cube is designed for.
The solution is a relational table that stores employee-level detail, combined with a Business Rule that reads the table, aggregates the data, and writes summary totals to the cube.
The pattern:
- Relational table — A custom database table (or MarketPlace People Planning table) with columns for EmployeeID, Name, Entity, Department, AnnualSalary, StartDate, EndDate, BenefitsRate, etc.
- Custom dashboard — An XFBR-powered form where HR and department managers can add, edit, and remove employee records (CRUD operations).
- Aggregation rule — A Spreadsheet or Extender Business Rule that reads the employee table, sums salary by Entity × Department × Month, and writes the totals to the cube.
Here is a simplified aggregation rule:
Specialty Planning: Capital Projects
Capital project planning follows the same relational-to-cube pattern as headcount, but with different detail fields:
- Project name, ID, and category
- Total cost and spend timeline (by month or quarter)
- Useful life and depreciation method (straight-line, declining balance)
- Start date and in-service date
A custom dashboard lets project managers enter and maintain their capital project list. An Extender or Spreadsheet Business Rule reads the project table, calculates monthly depreciation for each asset, and writes the results to the cube — both the CapEx spend (in the period it occurs) and the ongoing depreciation expense (spread over the useful life).
This pattern is especially valuable because depreciation calculations are tedious in a flat cube model (you would need separate accounts for every asset or complex time-shifting formulas). The relational table handles the detail, and the Business Rule distills it into the handful of cube accounts the P&L needs.
CRUD Patterns in OneStream
Both headcount and capital project planning follow the same architectural pattern: a relational table for detail, Business Rules for processing, the cube for aggregated results, and a dashboard for user interaction. This CRUD pattern (Create, Read, Update, Delete) generalizes to any specialty planning module.
The specific Business Rule types used at each step:
| CRUD Step | Rule Type | Purpose |
|---|---|---|
| Dashboard display | Dashboard DataSet | Read the relational table and return data for the grid |
| Save / edit | Dashboard Extender | Handle save events, validate input, write to relational table |
| Delete | Dashboard Extender | Handle delete events, remove rows from relational table |
| Aggregate to cube | Spreadsheet or Extender | Read table, perform calculations, write results to cube cells |
| Trigger from workflow | Data Management Extender | Run the aggregation rule as part of a Data Management sequence |
ABC Example: Rolling Forecast and People Plan
ABC Manufacturing implements two extensions beyond their annual budget:
Rolling Forecast
Each month, after the close, ABC runs a Data Management sequence that:
- Loads actuals for the closed month into the Actual scenario (using the integration pipeline from the Data Integration guide)
- Seeds actuals into Forecast_Working for closed months — replacing prior projections with what actually happened
- Recalculates Forecast_Working for open months — using the same driver-based logic as the budget, but with updated assumptions
- Publishes the snapshot — Once the forecast cycle is approved, copies Forecast_Working to the corresponding Forecast_MX (e.g., Forecast_M3 for the March cycle)
The Finance Business Rule handles steps 2 and 3 using the period-number comparison pattern shown earlier in this guide. The
lastClosedPeriod value is stored in a settings table and updated by the FP&A team each month. It controls both the seeding cutoff and which snapshot is the publish target.People Plan
ABC's People Plan tracks 500 employees across three entities. The module provides:
- A dashboard grid where HR managers can view, add, edit, and terminate employee records. Each row shows employee name, entity, department, annual salary, benefits rate, start date, and optional end date.
- An aggregation rule that runs nightly (or on demand) to read the employee table, calculate monthly salary and benefits by Entity × Department, and write the totals to the cube under the Forecast scenario.
- Integration with the P&L — The aggregated SalaryExpense and BenefitsExpense from the People Plan replace the simple FTE × AvgSalary driver calculation for entities that have completed their people planning. Entities still in draft mode fall back to the driver-based approach.
This hybrid approach — detailed people planning where it is ready, driver-based estimates where it is not — is a common pattern in large implementations. The Finance Business Rule checks a flag (stored in the cube or a settings table) for each entity to determine which calculation path to use.
Related Content
- Building a Budget — The budget calculations that the forecast extends and builds on
- Writing Calculations — Detailed coverage of Calculate, Data Buffers, and CustomCalculate
- Getting Started with Workspace Assemblies — Share code between Business Rules using compiled assemblies