UiPath Documentation
maestro
latest
false
Importante :
A localização de um conteúdo recém-publicado pode levar de 1 a 2 semanas para ficar disponível.

Guia do usuário do Maestro

Variables and data flow

O que é

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.

Como funciona

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.

Variáveis

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

Esta página foi útil?

Conectar

Precisa de ajuda? Suporte

Quer aprender? Academia UiPath

Tem perguntas? Fórum do UiPath

Fique por dentro das novidades