Variable Namespaces
When you build a workflow in the action builder, each action step can produce output and store it in a named variable. These variables let you pass data from one step to the next, chain lookups together, and build multi-step automations.
Variables are organized into namespaces. Some namespaces are system-provided: the system populates them automatically and you reference their values in expressions and text fields. Other namespaces are user-populated: you configure your action steps to store results into them.
| System-Provided | User-Populated | |
|---|---|---|
| Populated by | The system, before your actions run | Your action steps, as they execute |
| Examples | email, input, meta | custom, global, output |
| You can store action results here | No | Yes |
Which namespaces are available depends on the product you are working in. The sections below describe each product's namespaces individually.
{ shortcutIn any text field inside an action step, type { to open the variable autocomplete menu. Every available variable appears in the list, organized by namespace.
The custom Namespace
The custom namespace is available in every product and is the default storage location for all action results. Reference values with {{custom.variableName}}.
When you fill in the Store results in variable field on any action step, the result goes into custom unless you explicitly switch to a different namespace. Each step's output accumulates as the rule progresses: step 3 can reference variables set by steps 1 and 2, and nothing is lost within the same rule.
Use custom for carrying data between action steps within a single rule. In email processing, custom variables are reset when each rule finishes, so they do not carry over into the next rule. If you need to share data across rules, use the global namespace instead.
This is the namespace you will use for the vast majority of your workflow data. If you are unsure which namespace to use, use custom.
Email Processing
Email processing rules (hosted mailboxes and remote mailboxes) handle inbound email. They have access to the following namespaces:
System-provided
email: All inbound email properties, available from the start of every rule. Reference with {{email.propertyName}}. This includes the subject line, sender address, body content, recipients, and parsed body sections. See Email Data Properties for the complete list of available properties.
meta: Metadata about the current processing run.
| Variable | Description |
|---|---|
{{meta.history.id}} | Unique ID of this processing run |
{{meta.history.url}} | Direct link to this history entry |
{{meta.remote.id}} | (Remote mailboxes only) ID of the remote email on the source server |
{{meta.remote.url}} | (Remote mailboxes only) Link to the remote email if available |
User-populated
custom: General-purpose action results. Carries data between action steps within a single rule. Custom variables are reset when each rule finishes processing. A custom variable set in Rule Set 1 is not available in Rule Set 2. Use custom for working data that only needs to exist for the duration of the current rule.
global: A separate namespace designed specifically for persisting data across different rule sets. Unlike custom, global variables are not reset between rules. When email processing evaluates an inbound message, it runs each rule set top to bottom, and global variables accumulate across all of them.
Reference global values with {{global.variableName}}. To store an action's results in the global namespace, double-click the namespace badge on the action's result variable field to toggle from custom to global.
Example:
- Rule Set 1 looks up a contact and stores it in
{{global.contact}}. It also stores a ticket ID in{{custom.ticketId}}. - Rule Set 2 can read
{{global.contact.id}}to associate a ticket with that contact without repeating the lookup. However,{{custom.ticketId}}is no longer available becausecustomwas reset when Rule Set 1 finished.
This is the key reason global exists: to pass data between rules. Use custom for working data within a single rule, and global only when you specifically need a value to survive into subsequent rules.
Global variables accumulate across every rule set in the mailbox and are never reset during a processing run. Overusing global pollutes the variable namespace and makes it harder to understand where values come from. Unless you have a specific need to share data between rules, always use custom.
Macros
Macros are reusable units of automation that are called from other products. An email processing rule, a scheduled task, an AI agent, or another macro can call a macro using the Invoke Macro action. Macros accept inputs, do work, and return outputs to the caller.
System-provided
input: Arguments passed into the macro from the caller. Reference with {{input.propertyName}}.
When a caller invokes the macro, the values it provides appear in the input namespace. You define a macro's expected inputs in the macro's Input tab.
meta: Metadata about the current processing run ({{meta.history.id}}, {{meta.history.url}}).
User-populated
custom: General-purpose action results. Carries data between action steps within the macro.
output: The macro's return values. Reference with {{output.variableName}}. To store an action's results in the output namespace, double-click the namespace badge on the action's result variable field to toggle from custom to output.
Use output to define the data that is returned when the macro completes. The output values are most often consumed by the calling flow (the email processing rule, scheduled task, or AI agent that invoked the macro), not by other macros. Think of custom as scratch space for intermediate work and output as the structured result you hand back to the caller.
Example: An email processing rule calls a reusable "Look Up Contact" macro. Inside the macro, several lookup steps store intermediate results in custom variables. The final result is stored in {{output.contact}}. When the macro completes, the email processing rule receives the contact data and uses it to create a ticket, without seeing any of the macro's intermediate variables.
Scheduled Tasks
Scheduled tasks run on a timer without any triggering email or event. They have access to the following namespaces:
System-provided
meta: Metadata about the current processing run and schedule.
| Variable | Description |
|---|---|
{{meta.history.id}} | Unique ID of this processing run |
{{meta.history.url}} | Direct link to this history entry |
{{meta.scheduler.id}} | ID of the scheduled task |
{{meta.scheduler.name}} | Name of the scheduled task |
User-populated
custom: General-purpose action results. Carries data between action steps within the scheduled task.
Forms
Forms are public-facing web forms that trigger automation when someone submits them. The visitor's field values arrive in the input namespace, and the form's action list runs against that input.
System-provided
input: The values submitted through the public form. Reference with {{input.fieldName}}.
Each field defined on the form's Input tab becomes a property on input. Password fields are redacted in history logs.
meta: Metadata about the current processing run ({{meta.history.id}}, {{meta.history.url}}).
User-populated
custom: General-purpose action results. Carries data between action steps within the form. Forms do not have an output or global namespace; each submission is isolated.
Event Subscriptions
Event subscriptions trigger when an external integration sends an event (for example, a ticket update from your PSA). They have access to the following namespaces:
System-provided
Event source payload: The event data, available under a namespace named after the integration. The variable name depends on the event source:
| Integration | Namespace | Example |
|---|---|---|
| Autotask | autotask | {{autotask.ticket.id}} |
| ConnectWise PSA | connectwise-psa | {{connectwise-psa.ticket.summary}} |
| Halo PSA | halo | {{halo.ticket.id}} |
The exact properties available depend on the event type and the data the integration sends.
meta: Metadata about the processing run, the event, and the subscription.
| Variable | Description |
|---|---|
{{meta.history.id}} | Unique ID of this processing run |
{{meta.history.url}} | Direct link to this history entry |
{{meta.event.id}} | ID of the triggering event |
{{meta.event.source}} | Integration that sent the event |
{{meta.event.type}} | Type of event |
{{meta.event.external_id}} | External ID from the source system |
{{meta.event.occurred_at}} | When the event occurred |
{{meta.subscription.id}} | ID of the subscription |
{{meta.subscription.description}} | Description of the subscription |
User-populated
custom: General-purpose action results. Carries data between action steps within the subscription handler.
Variable Isolation in Nested Execution
When an email processing rule, scheduled task, or AI agent calls a macro (via Invoke Macro), the system creates an isolated scope. The called macro gets a fresh set of variables and cannot see or modify the caller's custom, global, or other namespace values. When execution returns to the caller, the original variables are restored.
This means you can safely call reusable macros without worrying about variable name collisions. The only data that crosses the boundary is the explicit input (going in) and output (coming back).
Inspecting Variables
Open any entry on the History page to see the full execution log. For each action step, expand the details to view the exact state of all variables before and after the step ran. This is the fastest way to verify that your variables contain the values you expect.
Quick Reference
| Namespace | Syntax | Type | Purpose |
|---|---|---|---|
custom | {{custom.name}} | User-populated | Carry data between action steps within a rule (all products; reset between rules) |
global | {{global.name}} | User-populated | Persist data across rule sets (email processing only) |
output | {{output.name}} | User-populated | Define macro return values (macros only) |
email | {{email.subject}} | System-provided | Inbound email properties (email processing only) |
input | {{input.name}} | System-provided | Arguments from the caller (macros) or public submission values (forms) |
meta | {{meta.history.id}} | System-provided | Processing run metadata (all products, properties vary) |
| (event source) | {{autotask.ticket.id}} | System-provided | Event payload from integration (subscriptions only) |
Related Documentation
- Core Concepts: processing hierarchy, email variables, and step chaining
- Expression Builder: use variables in rule expressions
- Email Processing: how rules and stop actions control processing flow
- Macros: build, test, and invoke reusable units of automation
- Forms: public forms that trigger automation when submitted
- Render Text and Store as Variable: create variables from text templates