For the complete documentation index, see llms.txt. This page is also available as Markdown.

Flow variables

Flows have access to a set of built-in variables that carry information about the running flow, such as the active environment, the identity the flow runs as, and details of the incoming request. These are the flow variables.

Flow variables appear in the Flow Data section of the data-binding dialog on any flow action. They can be bound to action node properties and referenced in conditions and filters, the same way app variables are used in apps. Their values are resolved at runtime when the flow runs.

Variable
Data type
Description

Active Environment

Enum

The environment the flow is running in, either Develop, Test, Staging, or Production. Resolves the same regardless of how the flow is run. Useful to alter functionality based on whether the environment uses production data (Staging and Production) or not.

Current User ID

Reference (User)

The identity the flow is running as. See Identity.

Principal User ID

Reference (User)

The user who originated the run. See Identity.

Service Account ID

String

The service account the flow is running as, if any. Empty when the flow runs as a human user. See Identity.

Hostname

String

The host from the incoming HTTP request. See Request context.

IP address

String

The client IP address from the incoming HTTP request. See Request context.

Client HTTP Method

Enum

The HTTP method of the incoming request, for example GET or POST. See Request context.

Identity

Three flow variables describe the identity a flow is running under. They matter most when a flow can be run both directly by a person and automatically by a service account.

Current User ID is the effective identity the flow runs as. Principal User ID is the user who originated the run, and is always populated. Service Account ID is the service account in effect, and is empty when the flow runs as a human user.

When a flow runs on behalf of a person, Current User ID and Principal User ID both resolve to that person and Service Account ID is empty. When a flow runs as a service account, Service Account ID is populated and Current User ID resolves to the service account. Principal User ID stays with the person who initiated the run where there is one, so the human behind the call is preserved even when the flow acts as a service account.

Trigger
Current User ID
Principal User ID
Service Account ID

Run Flow from an app, as a normal user

the user

the user

empty

Run Flow from an app, with Run as Service Account

the service account

the user

the service account

API Endpoint called with a service account API key

the service account

the service account

the service account

the service account

the service account

the service account

Good to know

Current User ID and Principal User ID are id-only references to the User object class. They are used to reference a user object downstream, for example to filter a query or update the caller's own record, and resolve without a database read. The referenced user object cannot be browsed into from the binding. Service Account ID is a plain string and can be read directly.

Request context

Hostname, IP address, and Client HTTP Method describe the incoming HTTP request. They are populated only when the flow is run through an API Endpoint. For any other trigger, such as Run Flow from an app or a schedule, they resolve to empty and the flow continues without error.

Good to know

If you bind a request-context variable in an action that is not guaranteed to run from a web request, for example an action reachable only by a schedule, a non-blocking alert appears on the action at design time. The value will be empty in those runs. The alert does not prevent you from saving.

Resource files

The resource files uploaded to your solution are available in flows. A flow can use a resource file as a whole file, for example to attach it to an email with the Send Email action node or to pass its URL to a request.

Was this helpful?