Process store

The process store is a JSON object shared by a single process run. Tasks use it to pass data to each other: identifiers, arrays for loop iteration, intermediate results, and generated text.

Writing is done only via rules in the configuration of actions and “Template” elements. Reading is done via Go templates {{ .store.<path> }} in the request body, gateway conditions, and other fields that support templating.

Data model

• One store per run — each process instance has its own store; it is preserved between steps and available when viewing the run.
• Nested paths — keys are specified as dot-paths without a leading dot: notification.module_name, ctx.job.id. Intermediate objects are created automatically.
• Array indices — a path can reference an array element: items[0].status, branches[2].name.
• Value types — depending on the operation, strings, numbers, objects, and JSON arrays can end up in the store. The “Write string” and “Append string” operations always work with strings; operations with the JSON suffix store the parsed structure.

Store update rules

Rules are configured in the action: “Configuration” → “Update” → “Process store update”. They run after the action completes successfully, in list order. Each subsequent rule sees the changes made by the previous rules of the same action.

In the process task configuration, rules are shown in read-only mode; to change them, open the action from the task’s side panel.

Rule fields

Operations

For the Write JSON, Append JSON, and Merge JSON operations, it is convenient to use the toJSON function together with a direct reference to a response field, e.g. {{ .response.items }} — the platform will substitute the value without extra serialization.

Rule examples

Save an identifier from the action’s response:

Write an array for a subsequent loop:

Append a string to a log:

Update only part of an object:

Run a rule only on the first loop iteration:

Delete a temporary key after use:

“Store paths” panel

The action’s rule editor has a Store paths panel: it shows the loop context keys (_loop.item, _loop.index, etc.).

Reading from the store

In process templates, use:

{{ .store.<path> }}

For nested fields, the path matches the “Target” in the write rules:

{{ .store.notification.module_name }}
{{ .store.items[0].id }}

Process launch parameters are available in a separate context:

{{ .process.<parameter_identifier> }}

For more information on templating contexts, see Templating.

Loop context _loop

While the loop body is running, the _loop object is available in the store:

Examples in templates:

{{ .store._loop.item.name }}
{{ .store._loop.item.scan_type }}
{{ .store._loop.index }}

In exclusive gateway conditions inside a loop:

{{ eq .store._loop.item.branch .store.current_branch_tag }}

Looping over a collection from the store

The “Loop” element supports two modes (the “Loop mode” field):

1. Fixed number — the body runs a specified number of times (1–10000). _loop.item holds the iteration number (1, 2, 3…).
2. By collection — when entering the loop, the “Collection template” Go template is evaluated; each element of the resulting JSON array is one iteration.

Collection template

The recommended approach is a path to an array already written to the store by a previous task:

{{ .store.notification.engagements }}

An alternative is to build the array in the template:

{{ toJSON .store.modules }}

Edge cases:

• An empty array or a missing key — 0 iterations, execution follows the “Loop exit” connection; a warning appears in the process log.
• A value at the path that is not a JSON array — a validation or loop execution error.

Scenario: iterating over a list from an API

1. Task “Get engagements” — a Write JSON rule, target notification.engagements, source {{ toJSON .response.engagements }}.
2. Loop, By collection mode, collection template {{ .store.notification.engagements }}.
3. Task in the loop body — use {{ .store._loop.item.id }}, {{ .store._loop.item.name }} in the request body.
4. Exclusive gateway in the body — a condition based on an item field, e.g. left value {{ .store._loop.item.status }}, right value active.
5. Loop exit connection — continuation after iterating over all elements.

The Template element

The “Template” element evaluates a Go template as the process runs and writes a string to the store. JSON in the result is not parsed — the text is stored in the store as-is.

Example body:

## Report for {{ .store._loop.item.name }}

Status: {{ .store._loop.item.status }}
Owner: {{ .store._loop.item.owner }}

Subsequent tasks read the result via {{ .store.rendered_message }} or the corresponding path.

Viewing the store during execution

On the process run visualization screen, open the Store tab:

• Tree — navigate nested keys; the type and value of the selected node are shown on the right.
• JSON — the full contents of the store in JSON format.

You can copy a value, refresh the data, and download the run’s JSON (button on the run dialog panel).

The task’s side panel on the run diagram shows the selected action’s Process store update rules — useful for comparing the store’s actual contents against the configuration.

Process log and debugging

The visualization panel provides:

• an Execution log tab (including in a separate window or below the diagram);
• Download log — the run’s text log;
• messages about an empty loop collection and skipped store rules.

If a template error occurs, or invalid JSON is used in a rule with a JSON operation, that rule may be skipped (with a warning in the log), while the other rules of the same action continue to run.

Related sections

• Overview — diagram elements, running, and management.
• Updating the store from actions — where the rules are enabled.
• Templating — Go template syntax and contexts.