Run Calculation

The Run Calculation activity runs a calculation defined in the Una calculation engine — a calc script, a formula, a SQL calc or a model calc — passing parameters and waiting for it to complete before the workflow continues.

Purpose

Use the Run Calculation activity to:

• Trigger a model calculation as part of a workflow (e.g. recompute allocations after a data load)
• Pass dynamic parameters to a calculation at runtime
• Chain a calculation step between a data load and a report generation step
• Automate recurring calculations that currently require manual execution

Prerequisites

The activity works with calculations that meet all of the following criteria:

Requirement	Detail
Execution type	On Demand or Automatic. A Dynamic formula is evaluated at query time and cannot be run.
Compiled	The calculation has been compiled since it was last changed
No errors	It compiled without errors

A calculation that does not meet these criteria causes the activity to return Error at runtime. The editor only lists calculations that pass all three checks, plus the one already selected.

Configuration

Calculation

Select the calculation to run from the dropdown.

Parameters

When you select a calculation, the editor shows one field for each of its parameters — see Running Calculations for what each type of calculation declares.

Field	Description
A value	Static text, or interpolated: type { to pick a workflow variable
A member	Pick a member of the dimension, or use the { } button to enter a variable that holds a member key
A relationship (formulas)	How the member expands: Self, Self and descendants (the default), Descendants, Leaf descendants

• A parameter marked with * is required. The others can be left empty to use their default.
• The calculation runs as the user who started or scheduled the workflow. That user is never a parameter and is not listed.

Example:

Year     = {{var:ClosingYear}}
Scenario = {{var:CurrentScenario}}

Workflows saved before parameters were listed by the editor

Opening the activity brings its parameters in line with the calculation: a script parameter stored under its procedure name (_Year) is renamed to its declared name (Year), and a username entry, or any entry the calculation does not declare, is removed. Save the workflow to keep the change. Until then such a workflow keeps running: both names are accepted, and username is ignored.

After interpolation, unresolved {Key} patterns in parameter values trigger a warning in the workflow log but do not stop execution.

Timeout (seconds)

Maximum time in seconds the calculation is allowed to run.

• Default mount: 30 seconds
• Maximum configurable: 6000 seconds

Long-running calculations (complex allocations, large data sets) may require a higher timeout. Set it explicitly rather than relying on the default.

Behavior

1. The calculation name and all parameter values are interpolated.
2. The system looks up the calculation by name and checks it (execution type, compile errors). If a check fails, the activity logs the reason and returns Error.
3. The parameters are checked against the calculation's own: a name it does not declare, a required parameter without a value, or a value of the wrong type (text where a number is declared) is logged, and the activity returns Error without running anything.
4. The calculation's stored procedure is executed as the user who started the workflow.
5. On success the activity returns Success. On any SQL exception, the error message is logged and the activity returns Error.

Usage Patterns

Load Then Calculate

ETL ("Import_Actuals") ──> Run Calculation ("AllocateOverheads")
                              └── Parameters: Period = {{var:Period}}

Calculate Per Entity in a Loop

Foreach: entity in entities
  └──> Run Calculation ("EntityClose")
         Parameters: EntityId = {{foreach:item}}
                     Period   = {{var:Period}}

Validate Result After Calculation

Run Calculation ("ComputeVariances")
 ├─[Success]──> Run Calculation ("AggregateResults")
 └─[Error]────> Email ("Calculation failed — {{var:Period}}")

Usage Notes

• The calculation runs synchronously — the workflow waits for it to complete before moving on.
• Changes to the calculation (logic changes) take effect once it is compiled — no workflow republish required. If parameters are added, removed or renamed, or the calculation is renamed, open the activity and update it.
• The dropdown in the editor shows calculations at edit time. If a calculation is deleted or becomes invalid after the workflow is saved, the activity will fail at runtime with an appropriate error message.

Best Practices

• Always wire an error arrow. Calculation failures (errors, timeouts, missing calculations, refused parameters) should route to a notification activity.
• Name the activity after the calculation it runs (e.g. "Calculate: Overhead Allocations") so the workflow diagram is self-documenting.
• Set an explicit timeout for calculations you know are slow. The 30-second default will cause spurious failures for complex scripts.
• When iterating over entities, confirm the calculation is idempotent — running it twice for the same entity and period should produce the same result.

JSON Reference

{
  "discriminator": "RunCalcWorkflowActivity",
  "activityId": "<uuid>",
  "name": "Run Calculation",
  "positionX": 0,
  "positionY": 0,
  "advanceRule": 2,
  "calcName": "CalculateOverheads",
  "timeoutInSeconds": 120,
  "parameters": [
    { "key": "Period", "value": "{Period}" },
    { "key": "Entity", "value": "{Entity}" }
  ]
}

Property	Type	Description
calcName	string	Corresponds to the Calculation field. The name of the calculation to run. Supports {variable} interpolation.
timeoutInSeconds	integer | null	Corresponds to the Timeout field. Maximum execution time in seconds. null uses the default timeout.
parameters	array	Corresponds to the Parameters fields. Array of { "key": string, "value": string } objects: key is the parameter's declared name without @, value its value as text. An entry with an empty value is not passed.