Flow Designer Data Pills and Variables in ServiceNow: The Complete Reference

What is a data pill?

A data pill is a reference to a value that was produced by an earlier part of the flow. Every source of data in Flow Designer produces data pills — the trigger, action steps, script steps, subflow outputs, and flow variables. When you drag a data pill into a step's input field, you are saying "use the value that was produced there in this step."

Data pills are resolved at runtime — they are not copies of values but references that are evaluated when the step executes. This distinction matters for understanding some of the behaviour described later in this guide.

Trigger data pills

For a record-based trigger, the trigger produces a data pill for the record itself and one pill per field on that record. These are available throughout the entire flow:

// Record trigger on Incident table produces:
Trigger > Incident Record                    — the full record reference
Trigger > Incident Record > Number           — the incident number (string)
Trigger > Incident Record > Short description — the short description
Trigger > Incident Record > State            — the state value
Trigger > Incident Record > Assigned to      — the assigned_to field (reference)
Trigger > Incident Record > Priority         — the priority value
... (one pill per field on the table)

Record vs field pills

There is an important distinction between a record pill and a field pill:

• A record pill (like Trigger > Incident Record) represents the full GlideRecord object. When passed to a step that accepts a record reference, it provides access to all fields. It can be dot-walked to access individual fields.
• A field pill (like Trigger > Incident Record > Number) represents a specific scalar value — a string, integer, date, or reference sys_id. When passed to a step that expects a string, it resolves to the field value.

Previous values in update triggers

For record-updated triggers, Flow Designer provides access to the previous values of the record — the values before the update that triggered the flow:

Trigger > Incident Record > State              — current state value
Trigger > Incident Record > Previous > State   — state value before this update

This is the equivalent of current.state vs previous.state in a Business Rule. Use it when your flow logic depends on what changed, not just what the current value is.

Step output pills

Every action step and script step that produces output creates data pills in subsequent steps. The output pills from a step are only available in steps that come after it in the flow — not before.

Look Up Records output

Step: Look Up Records → sys_user (filter: sys_id = assigned_to pill)
Outputs:
  → Look Up User Record > User Record          — the full user record
  → Look Up User Record > User Record > Name   — the user's display name
  → Look Up User Record > User Record > Email  — the user's email
  → Look Up User Record > User Record > Department > Name  — dot-walked department
  → Look Up User Record > Record Count         — number of matching records (0 or 1 for single lookup)

Create Record output

Step: Create Record → task
Outputs:
  → Create Task Record > Task Record           — the newly created record
  → Create Task Record > Task Record > Number  — the task number
  → Create Task Record > Task Record > Sys ID  — the sys_id of the new record

REST Action output

Step: REST Action (GET request to external API)
Outputs:
  → REST Action > Response Body                — raw response body (JSON string)
  → REST Action > Status Code                  — HTTP status code (200, 404, etc.)
  → REST Action > Response Headers > Content-Type
  → REST Action > Error Message                — populated if the call failed

Dot-walking in data pills

Data pills support dot-walking through reference fields. Expanding a reference field pill reveals the fields of the referenced record — the same dot-walking available in scripting with current.assigned_to.department.name.

// In scripting:
var deptName = current.assigned_to.department.getDisplayValue();

// Equivalent data pill in Flow Designer:
Trigger > Incident Record > Assigned to > Department > Name

Each level of dot-walking adds a join in the underlying query. Two or three levels deep is typically fine; deeply nested dot-walking (5+ levels) may affect performance on large datasets.

Display value vs raw value

Reference field pills resolve to the display value by default when used in text fields and notifications. When you need the sys_id of a referenced record rather than its display name, use the Sys ID child pill:

// Display value: "John Smith"
Trigger > Incident Record > Assigned to > Name

// Sys_id: "6816f79cc0a8016401c5a33be04be441"
Trigger > Incident Record > Assigned to > Sys ID

Flow variables

Flow variables are the persistent storage layer of Flow Designer. Unlike step output pills (which are only available in subsequent steps), flow variables can be read from any step, in any branch, at any point in the flow.

Creating flow variables

Define flow variables in the flow's properties: click the flow name in the canvas header → Properties → Flow Variables. Set a name, type, and optionally a default value.

Example flow variables:
  retry_count (Integer, default: 0)
  processing_complete (Boolean, default: false)
  error_occurred (Boolean, default: false)
  output_message (String)

Setting flow variables

Use the "Set Flow Variable" step (Flow Logic category) to assign a value to a flow variable. The value can be a static value, a data pill from any previous step, or a calculated value from a Script step.

Reading flow variables

Flow variable pills appear in the data pill picker under "Flow Variables". They are available in every step regardless of where in the flow the variable was last set.

Key use case — accumulating values across a For Each loop

Data pills produced inside a For Each loop only exist within that loop iteration — they are reset on each iteration. To accumulate values across iterations (counting matches, building a list), use a flow variable:

// Before the loop: Set Flow Variable "match_count" = 0

// Inside For Each loop:
//   Condition: does this record meet my criteria?
//   If yes: Set Flow Variable "match_count" = match_count + 1

// After the loop: match_count contains the total

Script step inputs and outputs

Script steps are a bridge between the data pill system and procedural JavaScript. They accept data pills as named input variables, perform JavaScript logic, and produce named output variables as data pills for subsequent steps.

Defining script step inputs

In the Script step configuration, add input variables in the Inputs section. Each input has a name and a type. Map data pills to these inputs in the step configuration.

Script step inputs:
  incident_number (String) ← Trigger > Incident Record > Number
  priority (String) ← Trigger > Incident Record > Priority
  assigned_to_email (String) ← Trigger > Incident Record > Assigned to > Email

Accessing inputs in the script

// In the Script step body, inputs are accessed via fd_data:
var incidentNumber = fd_data.incident_number;
var priority = parseInt(fd_data.priority);
var assignedEmail = fd_data.assigned_to_email;

// Build your logic:
var subject = 'P' + priority + ' Alert: ' + incidentNumber;
var shouldEscalate = priority <= 2 && assignedEmail !== '';

// Set outputs:
outputs.email_subject = subject;
outputs.should_escalate = shouldEscalate;

Defining and setting outputs

Add output variables in the Script step's Outputs section. Set them in the script using outputs.variable_name = value. After the script step executes, output variables are available as data pills:

→ Script — Build Email Content > Email Subject
→ Script — Build Email Content > Should Escalate

Subflow input and output pills

After a Run Subflow step executes, the subflow's output variables become data pills in the parent flow:

Step: Run Subflow — Create Jira Issue from Incident
  Inputs mapped: incident_record, jira_project_key

After step executes:
→ Run Subflow — Create Jira Issue > Jira Issue Key
→ Run Subflow — Create Jira Issue > Creation Success
→ Run Subflow — Create Jira Issue > Jira Issue URL

For the complete subflow patterns, see the subflows guide.

Data pill limitations

Limitation 1 — Loop-scoped pills do not persist

Data pills produced inside a For Each loop are scoped to that iteration. When the loop ends, those pills are not available outside the loop. Use flow variables to carry values out of a loop.

Limitation 2 — Pills are resolved at step execution time

If a record is updated between two steps that reference the same field pill, the second step still sees the value from when the record was first fetched — not the updated value. If you need the current value after a record update, do a new Look Up Records step.

Limitation 3 — Pills cannot be used directly in conditions

Condition steps in Flow Designer use a simplified condition builder. Complex comparison logic — combining multiple fields with AND/OR, comparing a field to a computed value — may require a Script step that evaluates the condition and produces a boolean output variable, which the Condition step then checks.

Limitation 4 — Pills from deactivated steps are unavailable

If you deactivate a step that produces pills used by later steps, those downstream steps will fail at runtime. Check for pill dependencies before deactivating steps.

Common data pill mistakes

Mistake 1 — Using a record pill where a field pill is needed

// Wrong — passing a full record pill where a string is needed
Send Email > To: [Look Up User > User Record] // passes the entire record object

// Right — pass the email field pill
Send Email > To: [Look Up User > User Record > Email]

Mistake 2 — Expecting loop pills outside the loop

// Wrong — trying to use a pill from inside the loop after it ends
For Each: Incident Records
  → produces: For Each > Incident Record pill
End of loop
Step: Update Record using "For Each > Incident Record" pill
// Error — this pill is no longer available after the loop

// Right — use flow variables to carry data out of the loop

Mistake 3 — Accessing display value vs raw value incorrectly

When you need a sys_id (to pass to a subflow or use in a REST call), use the Sys ID child pill. When you need the human-readable name (for a notification or log message), use the Name or display field child pill. Mixing these up causes silent failures or incorrect behaviour.