Process chaining allows you to run multiple Processes in sequence as a single workflow. A parent Process triggers one or more child Processes in a defined order, passing parameter values to each. This is the foundation of automated multi-step workflows in the platform.
Chaining is used to:
Break complex logic into smaller, focused Processes that are easier to maintain and test
Pass control and parameter values from one Process to the next
Repeat calculations across multiple items — for example, running the same calculation for each record in a list
Control execution flow, running different Processes depending on conditions
Prevent certain Processes from being run directly by end users
The mechanism is the EU_RUN_PROCESS object. When a Process writes records to EU_RUN_PROCESS, the platform queues and executes each listed Process in sequence. See Special Platform Objects for more on this object.
How chaining works at runtime
When the parent Process executes, it produces a list of child Processes and their parameter values in a named range. This range is configured as a Process Output targeting EU_RUN_PROCESS. After the parent completes, the platform reads that output and submits each child Process to the execution queue in order.
Child Processes execute sequentially. If any Process in the chain fails, the entire chain stops — outputs from all Processes in the chain are rolled back, and subsequent Processes in the list are not executed. The Calculation Log of the parent Process records the full chain execution, and the parent's overall status reflects the success or failure of the entire chain.
This all-or-nothing behaviour means chained Processes behave as a single logical unit. If partial success is acceptable, you need to design the chain accordingly — for example, by having the parent handle failure conditions explicitly rather than relying on a hard abort.
Prepare the Process Logic workbook
The parent Process needs a worksheet containing the chain definition — a list of child Processes to run, in order. Each row represents one child Process.
The structure of this list must match the EU_RUN_PROCESS object:
Column 1: Process Name — the exact name of the child Process to execute. If this cell is blank, the row is skipped and that Process is not run. Use this to conditionally exclude Processes using Excel formulas.
Column 2: Parameter string — all parameters required by the child Process, in the format:
ParameterName=Value;ParameterName=Value. The parameter names must exactly match those configured on the child Process. Dates within the parameter string use the formatdd/mmm/yyyy.
Example parameter string:
Transaction Date=01/Jan/2025;Region=North
You can use Excel formulas in both columns to generate process names and parameter values dynamically based on inputs, calculated values, or Process Parameters from the parent.
Create the parent Process
Any standard Spreadsheet Process can act as a parent (control) Process — there is no special Process Type for chaining. The parent Process runs its own workbook logic, then triggers child Processes via a EU_RUN_PROCESS output.
Create the parent Process as a standard Spreadsheet Process. See Create and Configure a Process.
Configure any required Process Parameters, Inputs, and other Outputs as needed.
In the Process Output section, add an output:
Location — the named range in the workbook containing the process list.
Object Specification —
EU_RUN_PROCESS.
Enter an Audit Comment and click Save and Refresh.
Design principles
Keep each Process in a chain focused on a single responsibility. A chain of five simple Processes is far easier to troubleshoot than one monolithic Process that does everything. When something fails, a smaller Process produces a smaller, more readable Calculation Log, and the problem is easier to isolate.
Use Control Processes to validate parameters and conditions before triggering calculation Processes. See Control Processes for that pattern.
Avoid very large chains in a single EU_RUN_PROCESS output. If a chain fails, the entire set is rolled back. Think carefully about where rollback boundaries should be and whether the chain should be broken into separate user-triggered steps for auditability.