- Einleitung
- Erste Schritte
- Prozessmodellierung mit BPMN
- Grundlagen der Prozessmodellierung
- Öffnen der Modellierungsarbeitsfläche
- Modellierung Ihres Prozesses
- Ausrichten und Verbinden von BPMN-Elementen
- Autopilot for Maestro (Vorschau)
- Prozess-Repository
- Prozessmodellierung mit Fallverwaltung
- Entwerfen eines persistenten Schemas für eine Fallentität
- Definieren von Fallschlüsseln (system vs. extern)
- Festlegung von Aufgaben-E/A und Write-Back-Vereinbarungen
- Austrittsregeln und Frühphasenbeendigung
- Modellierung von primären und sekundären Phasen
- Auslösen eines Falls über Data Fabric
- Implementieren von Personen und Berechtigungen auf Phasenebene
- Festlegen von SLAs und Regeln für die automatisierte Eskalation
- Konfigurieren einer Nachbearbeitungsschleife (erneuter Eintritt)
- Verwalten von Live-Fallinstanzen: Anhalten, migrieren und wiederholen
- Wörterbuch für die Fallverwaltungskomponente von Maestro
- Process modeling with Flow
- Erste Schritte
- Kernkonzepte
- Node reference
- Built-in nodes
- Connector nodes
- Build guides
- Best Practices
- Referenz (Reference)
- Prozessimplementierung
- Debugging
- Simulieren
- Veröffentlichen und Aktualisieren von agentischen Prozessen
- Häufige Implementierungsszenarien
- Extraktieren und Validieren von Dokumenten
- Prozessabläufe
- Prozessüberwachung
- Prozessoptimierung
- Referenzinformationen
Benutzerhandbuch zu Maestro
Dieser Leitfaden umfasst Folgendes:
Nodes in Flow don't automatically share data. When a node produces output — like an HTTP response or a computed value — downstream nodes access that output explicitly through expressions. Variables and data flow is how you wire data between nodes and persist values across your process.
There are two ways data moves through a process:
- Node output — each node produces output that downstream nodes can reference
- Variables — process-level variables you define to store and pass values between nodes
For the full expression grammar, operators, and how to write $vars references, see Expression syntax.
Wie es funktioniert
Node output
Every node that produces data makes it available through $vars.<nodeName>.output. The node name is auto-assigned based on the node type — for example, the first HTTP Request node is named httpRequest1, the second is httpRequest2.
You can see a node's variable name in the properties panel when the node is selected.
// Access HTTP Request response
$vars.httpRequest1.output.body
$vars.httpRequest1.output.statusCode
// Access Script return value
$vars.script1.output
// Access a second HTTP Request
$vars.httpRequest2.output.body
// Access HTTP Request response
$vars.httpRequest1.output.body
$vars.httpRequest1.output.statusCode
// Access Script return value
$vars.script1.output
// Access a second HTTP Request
$vars.httpRequest2.output.body
The output structure depends on the node type. Refer to each node's reference page for its specific output shape.
Variablen
Variables are process-level values that persist for the duration of a single execution. You define them in the Variables tab of the properties panel.
Each variable has:
- Name — how you reference it in expressions (e.g.,
$vars.orderTotal) - Type — String, Number, Boolean, Object, or Array
- Direction — input, output, or bidirectional
When to use variables vs node output:
- Node output fits data that passes from one node to the next. This is the most common pattern.
- Variables fit values that must be accessible across the entire process, or values that define inputs and outputs for the process itself.
Naming variables clearly: Descriptive, lowercase names with hyphens or camelCase — such as customerEmail, invoiceTotal, apiResponse — remain readable in execution traces over time. Single-letter names and abbreviations lose meaning quickly.
Trigger inputs
Input variables are owned by their trigger, not by the process. When a trigger fires, its inputs are available as $vars.<triggerName>.output.<inputName>:
// Access an input defined on a Manual Trigger named "manualTrigger1"
$vars.manualTrigger1.output.userId
// Access an input defined on a Manual Trigger named "manualTrigger1"
$vars.manualTrigger1.output.userId
This applies to all trigger types. If your process has multiple triggers, each trigger owns its own inputs — downstream nodes reference the specific trigger that started the execution.
Variable definitions
Variable definitions live in the Variables tab of the properties panel. Each definition stores the variable name, type, and direction so the value can be referenced consistently during a run.
Variable updates
Variables can be updated by node configuration or by Script node output.
From any node — Update Variable section
Every node has an Update Variable section in the properties panel. The section stores a writable variable target (output or bidirectional direction) and the JavaScript expression assigned to it. The expression is evaluated after the node completes.
From a Script node — return value
A Script node's return value is accessible downstream as $vars.<scriptName>.output. The Script node also has the same Update Variable section as other nodes for direct variable writes:
// The return value becomes $vars.script1.output
return {
orderTotal: $vars.httpRequest1.output.body.price * $vars.httpRequest1.output.body.quantity
};
// The return value becomes $vars.script1.output
return {
orderTotal: $vars.httpRequest1.output.body.price * $vars.httpRequest1.output.body.quantity
};
Scoping rules
A node can access output from:
- Upstream nodes in the same scope — nodes at the same level that executed before it
- Parent container nodes — if the node is inside a subflow or loop, it can access the parent's scope
A node cannot access output from:
- Nodes in a different branch — if a Decision or Switch sent execution down a different path, those nodes' output is not available
- Nodes that haven't executed — output only exists after a node runs
Subflow scoping
Subflows create their own variable scope. Nodes inside a subflow can access:
- Other nodes within the same subflow
- The parent process's scope
Variables updated inside a subflow are namespaced to avoid collisions with the parent process. For example, a variable counter inside a subflow named subflow1 is referenced as $vars.subflow1.counter from outside the subflow.
The subflow's return value is accessible to the parent process as $vars.<subflowName>.output.
Parallel branches
Parallel branches have independent execution contexts. Mutating a variable inside one branch does not make that change visible in another branch. A Merge node consolidates outputs from parallel paths when the paths need to rejoin.
Patterns
Building dynamic strings
Template literals in a Script node combine variables and static text:
return `Hello ${firstName}, your order #${orderId} has shipped.`;
return `Hello ${firstName}, your order #${orderId} has shipped.`;
Accumulating values in a loop
An accumulator pattern uses an array initialized before the Loop node and appended to inside the loop body:
// Script node inside the Loop body
results.push(item.processedValue);
return results;
// Script node inside the Loop body
results.push(item.processedValue);
return results;
Keeping secret values out of logs
Secret variable values are masked in the UI but may appear in exported trace data. Logging them is a data exposure risk.
Practical example
A process that fetches a user from an API and routes based on their role:
Step 1 — HTTP Request (httpRequest1): GET https://api.example.com/users/42
Step 2 — Script (script1): Extract the user's role
const user = $vars.httpRequest1.output.body;
return {
name: user.name,
role: user.role,
isAdmin: user.role === "admin"
};
const user = $vars.httpRequest1.output.body;
return {
name: user.name,
role: user.role,
isAdmin: user.role === "admin"
};
Step 3 — Decision (decision1): Branch on admin status
Expression: $vars.script1.output.isAdmin === true
- True → grant admin access
- False → grant standard access
Zugehörige Seiten
- Expression syntax —
$varsgrammar, operators, where you write expressions, common errors - Script node — writing JavaScript, return values,
$varsaccess - Decision node — branching on expressions
- The Canvas — properties panel, Variables tab
- Dieser Leitfaden umfasst Folgendes:
- Wie es funktioniert
- Node output
- Variablen
- Trigger inputs
- Variable definitions
- Variable updates
- Scoping rules
- Subflow scoping
- Parallel branches
- Patterns
- Building dynamic strings
- Accumulating values in a loop
- Keeping secret values out of logs
- Practical example
- Zugehörige Seiten