Variables and data in a scenario

A scenario has three mechanisms for moving data around. They complement one another, and knowing which to pick saves a lot of pointless wiring.

1. Tokens on links

The main mechanism: a box produces a value, it travels along the link, possibly reshaped by a selector, and arrives at the next box’s input.

It is explicit and readable: the data flow is the drawing.

Use it for everything local — the result of one call consumed by the next.

2. Run variables

A named space, specific to the run:

• Set variable writes a value;
• Get variable reads it back;
• a variable-typed value reads it on the fly, in any field;
• {{name}} reads it inside a template (Transform template, Map);
• the vars object reads it inside a code action;
• Add to list and Remove from list can write directly into the source variable.

A run variable covers the environment for the duration of the run: a request using {{token}} will take the token the scenario set rather than the environment’s.

Use it for whatever is global to the run: a token, a correlation identifier, a counter — rather than dragging a link across the whole graph.

3. Parameters and outputs

• The Input / Param box declares one or more named parameters, each with its type. It emits a single object { name: value, … }.

  The values come, in order, from: the launch (interface or MCP), the command line (--param name=value), or an interactive prompt if the scenario reaches the box with no value available.

• The Output / Return box exposes a named result to the caller. A scenario called by a Run scenario action makes its outputs visible on the caller’s output:<name> port.

That is what makes composition possible: a “log in” scenario that returns a token, reused by the others.

Environments

A request action has an env port: wiring an environment into it (an environment-typed value, or an environment name) runs the call in that environment.

That is how you run the same scenario against staging then production without duplicating anything — pass the environment as a scenario parameter.

Resolution in headless mode

Every typed value resolves the same way in the interface and with no window: custom lists, enumerations, environment previews. A scenario that works in the interface works in CI.

An ambiguous environment name (two environments sharing a name) raises an explicit error: pass the identifier instead.

Converting parameters on the command line

--param receives text; Restorm converts it according to the parameter’s declared type:

Declared type	What you pass
Number	--param Seuil=42
Boolean	--param Actif=true (1, yes, on accepted)
Date calculation	A date, or an epoch timestamp
List	JSON: --param Ids='[1,2,3]'
Enumeration	The value, validated against the permitted set
Custom list	The label, converted to the value (Rouge → FF0000)
Environment	An environment name or identifier
Everything else	The raw string

An impossible conversion fails the launch with a clear message, rather than running with a wrong value.