Skip to main content

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-ProvidedUser-Populated
Populated byThe system, before your actions runYour action steps, as they execute
Examplesemail, input, metacustom, global, output
You can store action results hereNoYes

Which namespaces are available depends on the product you are working in. The sections below describe each product's namespaces individually.

The { shortcut

In 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.

VariableDescription
{{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:

  1. Rule Set 1 looks up a contact and stores it in {{global.contact}}. It also stores a ticket ID in {{custom.ticketId}}.
  2. 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 because custom was 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.

Use global sparingly

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.

Custom Workflows​

Custom workflows are reusable units of automation that are called from other products. An email processing rule, a scheduled task, or another workflow can call a custom workflow using the Execute Workflow action. Workflows accept inputs, do work, and return outputs to the caller.

System-provided​

input: Arguments passed into the workflow from the caller. Reference with {{input.propertyName}}.

When an email processing rule or scheduled task calls this workflow, the values it provides appear in the input namespace. You define a workflow's expected inputs when you configure it.

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 workflow.

output: The workflow'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 workflow completes. The output values are most often consumed by the calling flow (the email processing rule or scheduled task that invoked the workflow), not by other workflows. 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" workflow. Inside the workflow, several lookup steps store intermediate results in custom variables. The final result is stored in {{output.contact}}. When the workflow completes, the email processing rule receives the contact data and uses it to create a ticket, without seeing any of the workflow'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.

VariableDescription
{{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.

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:

IntegrationNamespaceExample
Autotaskautotask{{autotask.ticket.id}}
ConnectWise PSAconnectwise-psa{{connectwise-psa.ticket.summary}}
Halo PSAhalo{{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.

VariableDescription
{{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 or scheduled task calls a workflow (via Execute Workflow), the system creates an isolated scope. The called workflow 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 workflows 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​

NamespaceSyntaxTypePurpose
custom{{custom.name}}User-populatedCarry data between action steps within a rule (all products; reset between rules)
global{{global.name}}User-populatedPersist data across rule sets (email processing only)
output{{output.name}}User-populatedDefine workflow return values (workflows only)
email{{email.subject}}System-providedInbound email properties (email processing only)
input{{input.name}}System-providedArguments from the caller (workflows only)
meta{{meta.history.id}}System-providedProcessing run metadata (all products, properties vary)
(event source){{autotask.ticket.id}}System-providedEvent payload from integration (subscriptions only)