Run Calculation

The Run Calculation activity executes a Calculation Script defined in the Una calculation engine, passing parameters and waiting for the script 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 script 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 only works with calculation scripts that meet all of the following criteria:

Requirement	Detail
Type	Must be `Script` (not a formula-based calculation)
Execution type	Must be `On Demand` (not scheduled or triggered automatically)
No errors	The script must compile without errors
Code present	The script must have a non-null code body

Scripts that do not meet these criteria will cause the activity to return Error at runtime. The editor only lists scripts that pass all four checks.

Configuration

Calc

Select the calculation script to run from the dropdown. Only eligible scripts (Script type, On Demand, no errors, with code) are shown.

The name supports interpolation, so the script can be selected dynamically:

Allocations_{{var:Period}}

Parameters

Key/value pairs passed to the calculation script. Both key and value support interpolation.

When you select a script, the editor automatically populates the parameter list from the script's declared parameters. You can then set the value for each one. You can also add parameters manually if needed.

Field	Description
Name	Parameter name (without `@` prefix) — must match the script's declared parameter
Value	Value to pass — static or interpolated

Example:

Period   = {{var:ClosingPeriod}}
EntityId = {{var:CurrentEntity}}

Duplicate parameter names are a validation error — the workflow will not save if the same name appears more than once.

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 script is allowed to run.

Default mount: 30 seconds
Maximum configurable: 6000 seconds

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

Behavior

The calculation name and all parameter values are interpolated.
The system looks up the script by name. If not found, the activity logs an error and returns Error.
The script is validated (type, execution type, errors, code). If any check fails, the activity logs the specific reason and returns Error.
The script is executed as a stored procedure in the client database: [client].[<CalcName>].
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.
The calculation script runs as a SQL stored procedure ([client].[CalcName]). Parameters map directly to SQL procedure parameters (prefixed with @ by the engine).
Changes to the calculation script (added/removed parameters, logic changes) take effect immediately — no workflow republish required. However, if the script is renamed, update the activity configuration.
The dropdown in the editor shows scripts at edit time. If a script 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 (script errors, timeouts, missing scripts) 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 script 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 Name field. The name of the on-demand calculation script 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 list. Array of `{ "key": string, "value": string }` objects passed as SQL stored procedure parameters.

Purpose​

Prerequisites​

Configuration​

Calc​

Parameters​

Timeout (seconds)​

Behavior​

Usage Patterns​

Load Then Calculate​

Calculate Per Entity in a Loop​

Validate Result After Calculation​

Usage Notes​

Best Practices​

JSON Reference​