Workflows

Workflow Substitution Variables

OneStream provides substitution variables that resolve to the current workflow context at runtime. These variables let you write generic Business Rules, Transformation Rules, and Dashboard expressions that automatically adapt based on which Workflow Profile, Scenario, and Time period the user (or batch process) is operating in. Instead of hard-coding dimension member names into your rules, you reference the workflow variable and let the engine fill in the correct value.

Variable Reference

VariableResolves ToExample Value
WFFull workflow context string (Scenario/Time/Entity)Actual/2024M6/US_East
WFProfileName of the current Workflow ProfileRevenue_Import
WFProfileIndexIndex of the current profile in the hierarchy3
WFScenarioName of the current Scenario memberActual
WFTimeName of the current Time member2024M6
WFCubeName of the current CubeMainCube
All variables are retrieved through the same API call — BRApi.Workflow.General.GetWorkflowSubstitutionVariable(si, "VariableName"). The string you pass must match the variable name exactly (case-sensitive).

Using Variables in Business Rules

The most common use case is branching logic based on the current Scenario or Time. Rather than duplicating a Business Rule for each Scenario, you write one rule and let the substitution variable drive the behavior.
1' Get the current workflow scenario and time
2Dim wfScenario As String = BRApi.Workflow.General.GetWorkflowSubstitutionVariable( _
3  si, "WFScenario")
4Dim wfTime As String = BRApi.Workflow.General.GetWorkflowSubstitutionVariable( _
5  si, "WFTime")
6Dim wfProfile As String = BRApi.Workflow.General.GetWorkflowSubstitutionVariable( _
7  si, "WFProfile")
8
9' Use workflow context to branch logic
10If wfScenario = "Actual" Then
11  ' Run actuals-specific calculation
12  BRApi.ErrorLog.LogMessage(si, $"Processing actuals for {wfTime}")
13Else
14  ' Run forecast/budget calculation
15  BRApi.ErrorLog.LogMessage(si, $"Processing {wfScenario} for {wfTime}")
16End If

Using Variables in Transformation Rules

Transformation Rules run during the IVL (Import, Validate, Load) pipeline and have full access to workflow substitution variables. A common pattern is routing data to different accounts based on the Scenario — for example, mapping a source "Revenue" line to A#GLRevenue for Actual but to A#PlanRevenue for Budget.
The variables are resolved before the transformation expression is evaluated, so you can use them directly in conditional mapping expressions. If a Transformation Rule needs to apply different account mappings depending on whether the load is for Actual or Forecast, it reads WFScenario and branches accordingly — one rule handles every scenario.
💡Tip
Keep Transformation Rules scenario-agnostic where possible. Only branch on WFScenario when the source-to-target mapping genuinely differs between scenarios. Over-branching makes rules harder to maintain.

Using Variables in Dashboard Expressions

Dashboard parameters and XFBR string functions can reference workflow variables to build context-aware displays. Two common patterns:
  • Dynamic labels — Display the active context in report headers (e.g., "Revenue Report — Actual 2024M6") by reading WFScenario and WFTime and concatenating them into a label string.
  • Data Adapter filtering — Pass WFScenario or WFTime into a Data Adapter expression so the grid or chart automatically filters to the user's current workflow context without requiring manual parameter selection.
ℹ️Info
Workflow substitution variables are only available when the code is executing within a workflow context. If you call these APIs from a standalone Data Management sequence that is not tied to a workflow, the variables may return empty strings.

Conditional Logic Based on WFScenario

A practical pattern is using WFScenario in a Select Case / switch block to apply entirely different calculation models per scenario. This keeps all logic in a single Business Rule while still allowing each scenario to have its own formula.
ℹ️Info
WFScenario returns the Scenario member name (e.g., "Actual", "Budget_2024"). In simple configurations the scenario name aligns with the scenario type, but in complex setups multiple scenarios can share one type — branch on the scenario name, not the type.
1' Adjust calculation logic based on workflow scenario
2Dim wfScenario As String = BRApi.Workflow.General.GetWorkflowSubstitutionVariable( _
3  si, "WFScenario")
4
5Select Case wfScenario
6  Case "Actual"
7      ' Actuals: load from GL, no driver calculations
8      api.Data.Calculate("A#Revenue = A#GLRevenue")
9  Case "Budget", "Forecast"
10      ' Budget/Forecast: apply driver models
11      api.Data.Calculate("A#Revenue = A#Units * A#PricePerUnit")
12  Case "Plan"
13      ' Long-range plan: apply growth rates
14      api.Data.Calculate("A#Revenue = A#PriorRevenue * (1 + A#GrowthRate)")
15End Select
⚠️Warning
Always include a default or fallback branch. If a new Scenario is added to the application and your rule does not handle it, the calculation will silently skip — which is much harder to debug than an explicit error message.

Related Content