Steps and assigns

Documentation Index

Fetch the complete documentation index at: https://docs.twine.se/llms.txt

Use this file to discover all available pages before exploring further.

A running flow threads a single state object - the token - through every node in the graph. Nodes read values from the token and write values back to it. The most important part of the token is a string-keyed map called assigns; it is the primary way nodes share data.

​

Assigns

An assign is a named value held on the token. Assigns are how downstream nodes see what earlier nodes produced. Typical patterns:

• A step that fetches employees from a source system writes the list to an assign named employees.
• A later node reads that assign, iterates over it, and writes a transformed list to outgoing_employees.
• A final step reads outgoing_employees and sends it to the target system.

Several nodes exist specifically for managing assigns:

• Assign Read reads one assign and exposes its value on an output port.
• Assign Put writes a value coming in on an input port to a named assign.
• FlowAssign writes a single resolved value to an assign as its own step.
• FlowCompose builds a struct payload from per-field mapping specs and stores it under an assign.
• FlowDefault falls back to a computed value when an assign is nil or missing.

Assign names are free-form strings. Choosing consistent names across a flow is important; the editor shows which assigns are written by which nodes, and the run log refers to them by name.

​

Pipeline steps

A step is a named unit of work - an operation that reaches out to a source or target system, runs a calculation, or performs a side effect. The FlowAction node is how a step is invoked from a flow. A FlowAction configures:

• The step to run. Steps are grouped by system in the picker (for example, “Fortnox: Get all projects”). Every step has a stable internal key that persists in saved flows; the display name can change without breaking existing flows.
• The system integration the step should target, when the step talks to an external system.
• The step’s options. Each step declares its own typed option schema, and the editor renders a form from it.
• An on error policy. See Execution and error handling.
• An optional cache mode, described below.

When a FlowAction runs, it invokes the step and merges the step’s results back into the token’s assigns. Which assigns a step writes is declared by the step itself, so the editor can show what will be available downstream.

​

Step caching

Some steps are expensive - fetching a large list from a source system, for example. When the same step with the same inputs would be called more than once in a single run, the result can be memoised. Caching is per-run: the first invocation of a cached step populates the cache, and subsequent invocations with an equivalent cache key reuse the first result. Only the step’s assigns are cached; log entries and errors are not. Steps opt into caching by declaring a cache key. Not every step is cacheable; those that aren’t simply run again each time they are invoked. A FlowAction’s cache mode can be set to force, which bypasses the cache and forwards a signal to the step so any internal caches inside the step’s implementation can also be bypassed. This is the escape hatch for reruns that must see fresh data.

​

Reading dated properties

Domain entities in Twine - Employee, Schedule, TimeReport, and so on - carry their history as dated properties. A flow that works with these entities reads and writes dated properties through a handful of dedicated nodes:

• Attribute reads a dated property from a subject. It is the same node documented in the Data Engine attribute reference.
• FlowDatedPropertyPut writes one dated property to a struct held in an assign.
• FlowCompose, FlowAssign, and FlowDefault all accept dated-property reads as value sources, with optional as-of dates.

Attribute and the other Data Engine nodes appear in both engines’ node pickers because they are useful for transformation in either context.