Skip to main content

Variables

When you build an automation 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.

Every variable name starts with a group name, such as custom in {{custom.ticket}} or email in {{email.subject}}. Some groups are provided automatically: their values are ready before your first action runs, and you reference them in expressions and text fields. Other groups are set by your actions: you choose them as the place to store an action step's results.

Provided AutomaticallySet by Your Actions
Where the values come fromFilled in before your actions runYour action steps, as they run
Examplesemail, input, metacustom, global, output
You can store action results hereNoYes

Which variables are available depends on the type of automation you are working on. The sections below describe the variables available for each type.

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

Custom Variables​

custom variables are available in every automation and are the default place to store 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 switch the field's custom. prefix to another group. Later steps in the same action list can use earlier results: step 3 can reference variables set by steps 1 and 2.

Use custom for carrying data between action steps in the same action list. 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 email rules, use global variables instead.

You will use custom for the vast majority of your automation's data. If you are unsure where to store a result, use custom.

Email Processing​

Email processing rules (hosted mailboxes and remote mailboxes) handle inbound email. They have access to the following variables:

Provided automatically​

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

Set by your actions​

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 1 is not available in Rule 2. Use custom for working data that only needs to exist for the duration of the current rule.

global: Variables designed specifically for keeping data across different rules for the same email. Unlike custom, global variables are not reset between rules. Email Processing evaluates rules from top to bottom, and matching rules can read the global values that earlier rules stored.

Reference global values with {{global.variableName}}. To store an action's results in a global variable, double-click the custom. prefix on the action's Store results in variable field to switch it to global..

Example:

  1. Rule 1 looks up a contact and stores it in {{global.contact}}. It also stores a ticket ID in {{custom.ticketId}}.
  2. Rule 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 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 carry over across rules for the same email; they do not carry over to another email. Overusing global clutters the variable list 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 included with Developer Toolkit. An email processing rule, a scheduled task, an Agentic Action, or another macro can call a macro using the Invoke Macro action. Macros accept inputs, do work, and return their output to the calling automation.

Provided automatically​

input: Values passed into the macro by the calling automation. Reference with {{input.propertyName}}.

When an automation calls the macro, each value it passes in becomes an {{input.propertyName}} variable. 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}}).

Set by your actions​

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 an output variable, double-click the custom. prefix on the action's Store results in variable field to switch it to output..

Use output to define the data that is returned when the macro completes. The calling automation reads these values, whether it is an email rule, scheduled task, Agentic Action, or another macro. Think of custom as scratch space for intermediate work and output as the structured result you hand back to the calling automation.

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 variables:

Provided automatically​

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

Set by your actions​

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 as {{input.fieldName}} variables, and the form's action steps use those values.

Provided automatically​

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}}).

Set by your actions​

custom: General-purpose action results. Carries data between action steps within the form. Forms do not have output or global variables; each submission starts fresh.

PSA Workflows​

In PSA Workflows, an event subscription starts an automation when your PSA sends a matching event, such as a ticket update. Its action steps have access to the following variables:

Provided automatically​

Event data: The event details, available under a group named after the integration:

IntegrationVariable groupExample
Autotaskautotask{{autotask.ticket.id}}
ConnectWise PSAconnectwise{{connectwise.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

Set by your actions​

custom: General-purpose action results. Carries data between action steps within the subscription handler.

Variables When Calling a Macro​

A macro works like a self-contained unit with its own private set of variables. When an email processing rule, scheduled task, Agentic Action, or another macro calls a macro with Invoke Macro, data crosses between them in only two places: the inputs you pass in, and the output the macro returns.

  • Steps inside the macro cannot read or change the calling automation's custom, global, or email variables. If the macro needs one of those values, add it to the macro's inputs and pass it in, for example {{email.subject}} or {{global.contact.id}}.
  • The calling automation cannot see the macro's custom variables. It receives only the macro's output, in the variable named in the Invoke Macro step's Store results in variable field.
  • After the macro finishes, the calling automation's variables are exactly as they were before, apart from that result variable.

This means you can safely call reusable macros without worrying about variable names clashing.

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​

GroupSyntaxTypePurpose
custom{{custom.name}}Set by your actionsCarry data between steps in the same action list; reset between email rules
global{{global.name}}Set by your actionsCarry data across rules for the same email (Email Processing only)
output{{output.name}}Set by your actionsDefine macro return values (macros only)
email{{email.subject}}Provided automaticallyInbound email properties (email processing only)
input{{input.name}}Provided automaticallyValues passed in by the calling automation (macros) or public submission values (forms)
meta{{meta.history.id}}Provided automaticallyProcessing run metadata (all automations, properties vary)
(event source){{autotask.ticket.id}}Provided automaticallyEvent payload from integration (subscriptions only)