A session variable is a named value that the entire automation can read and write while it runs. Its main usage is making data accessible downstream in another automation. It lives from the first step of a run to the last — and no longer. When the run ends, all session variables are discarded.
Overview
The Variable node creates session variables. Every step in the same run can access the same session variable by name. A new run of the automation starts with an empty set; values left behind by a previous run are not accessible. If data needs to outlast a single run, write it to a Storage record instead. Sub-automations get their own isolated variable set and do not share state with the parent unless values are passed explicitly.
Variable node session scope diagram
Operations
Session variables support three operations: Set, Get, and Clear.
Set Session Variables
Sets the value of one or more session variables. Define each variable with a name and a field type (String, Number, Integer, Boolean, Object, or Array). You can nest variables under a parent. Use "Add Session Variable" to add variables, "Use Code Snippet" to define them from JSON, or "Map from step" to link values from a previous node.
Get Session Variables
Retrieves the values of session variables that were previously set. Define the variable schema (name and type) for the variables you want to read, and the node returns their current values. Use "Add Session Variable," "Use Code Snippet," or "Map from step" to specify which variables to retrieve.
Clear Session Variables
Clears or removes one or more variables from the session. Provide the variable keys to clear. You can use dot notation (e.g., user.email) to clear nested variables. The output includes the list of cleared keys, the count of cleared variables, and any keys that were not found.
Session Lifetime
A session variable is created when a Set operation runs during an automation run, and it exists until the run completes. It is not persisted: each new run of the automation begins with no pre-existing variables, regardless of what previous runs set. This makes session variables safe for working state — you never accidentally read a stale value from a prior execution.
Data that must survive between runs belongs in a Storage record, not a session variable. If you need the result of run N to influence run N+1, write it to Storage at the end of the run and read it at the start of the next.
Sub-Automation Scope
A sub-automation gets its own isolated set of session variables. The parent and child do not share variable state: a variable set in the parent is not visible inside the sub-automation, and a variable set inside the sub-automation is not visible in the parent. To share data across the boundary, pass values in as sub-automation inputs and receive values out as explicit outputs that the parent maps to its own variables.
Notes
Keep the following in mind when designing automation variable usage.
Session variables are scoped to a single run — they are not persisted between runs.
The main usage of session variables is making data accessible downstream in another automation.
Sub-automations have isolated variable scope; pass values explicitly if cross-boundary sharing is needed.
For data that must survive between runs, write it to a Storage record.
There is no built-in increment operation — use Get, compute, Set to update numeric values.
For concurrent atomic increments across parallel branches, use a Storage field's Increment operation instead of a session variable.
If your automation relies on values produced by a previous run, redesign to read those values from Storage rather than session variables.