Workflow State v2
The Runtime keeps transient state for each Workflow activation. It holds current Parameters and Step Returns, execution frames, deferred values, and internal progress needed to complete that run.
Activation lifetime
A new activation starts with new state. Ordinary Debug, Run Now, HTTP, MCP, Schedule, and Sub-Workflow calls do not share this state with earlier runs.
A long-running listener is different: one listener activation can yield several events. Its activation state remains available until the listener completes, stops, restarts, or is replaced.
The Runtime releases managed Streams, enumerators, and replay resources when their owning scope or activation ends.
Node state
A published Node Method can request a thread-safe custom-state dictionary. The Runtime supplies the same dictionary to state-enabled Node Steps within the same Workflow activation, although each Step has its own Node instance.
This allows a Node implementation to coordinate operations during the current activation. The Node owns its entry names and value handling; this dictionary is not directly accessible to the Workflow itself.
Isolation boundaries
Sub-Workflows run as separate Workflow instances and have separate state. They receive mapped Parameters and return mapped values rather than sharing the parent's internal state.
Activation state is not durable storage. Do not use it for values that must survive a restart, listener replacement, deployment, or later Workflow run. Store durable business or checkpoint data with the Key/Value Node, or in an appropriate external system through a Connection.
Durable values across runs
The Key/Value Node stores small text or structured values without requiring a Connection. Records belong to a named Collection in the current Site Environment, so Test and Production do not share the same records. Use SetSingle and GetSingle for one key, or Set and Get for batches and date-range queries. A serialized value can contain up to 32 KB.
For example, after a target confirms that an order was created, store the source order ID as the key and the target ID as its value. A later run can retrieve that value before deciding whether to create or update the target. The provider write and the stored value are separate operations, so also account for a failure between them. See Eventual Consistency for the recovery pattern and Key/Value Management Screen for inspecting collections and managing retained records.
See also
See Execution order, Sub-Workflows, and Activation Modes and Timeouts.