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 “Set 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, on the “Update” tab, in the “Updating process store” section. 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 Set JSON, Append JSON, and Merge JSON operations, the source must render valid JSON: pass the value through toJSON, for example, {{ toJSON .response.items }}. If the source is a single path, such as {{ .response.items }}, the portal substitutes the value at this path without 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:

“Loop context” panel

The action’s rule editor has a Loop context panel: it shows the loop context keys (_loop.item, _loop.index, etc.). Click a key to insert it into a rule.

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 }}

Read an array element with the index function:

{{ (index .store.items 0).id }}

An index in square brackets, such as items[0].id, works only in write paths, for example in the “Target” field of write rules. In a Go template it fails the step with an error.

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 count — the body runs a specified number of times (1–10000). _loop.item holds the iteration number (1, 2, 3…).
2. Foreach collection — when entering the loop, the “Collection template” Go template is evaluated; each element of the resulting JSON array is one iteration. The array can contain up to 10,000 items.

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 “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 Set JSON rule, target notification.engagements, source {{ toJSON .response.engagements }}.
2. Loop, Foreach 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. 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. Compare them with the actual contents of the store to find a rule that did not run.

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.

Additional resources

• Processes overview
• Updating the process store from actions
• Templating: process store