Data pills

---
title: Data pills
description: Each time you add an action to a flow, Workflow Studio adds a data pill to store its results. The data pill name indicates its sequence in the flow and its data type.
locale: en-US
canonical_url: https://www.servicenow.com/docs/r/australia/build-workflows/workflow-studio/data-population.html
release: australia
product: Workflow Studio
classification: workflow-studio
topic_type: concept
last_updated: "2026-11-03"
reading_time_minutes: 5
breadcrumb: [Explore flows, Flows, subflows, and actions, Workflow Studio, Build workflows]
---

# Data pills

Each time you add an action to a flow, Workflow Studio adds a data pill to store its results. The data pill name indicates its sequence in the flow and its data type.

Flow designers use action result data pills to provide input for other flows, actions, or subflows. Flow designers can use the sequence value in the data pill name to confirm that they select the correct data pill value. When a flow runs an action, it generates the data pill runtime value as it is used. For example, suppose that a data pill for **\[Trigger->Incident record\]** gets populated with incident record values at the start of a flow. When the incident record values are updated, the data pill reflects the updated real-time values for the rest of the flow.

## Data pill population

Workflow Studio populates data pill values when the action, flow logic, or subflow that produces the data pill finishes running. If another action, flow logic, or subflow runs and changes the data pill value, then the new value is used for the rest of the flow. For example, suppose that you have a flow triggered by the creation of an incident record that performs the following actions.

\[Omitted image "example-flow-data-population.png"\] Alt text: Flow illustrating when data pill values are set

1.  **Set Flow Variables** flow logic to store the value of the **\[Trigger->Incident Record->Short description\]** in the **original-short-description** flow variable.
2.  **Update \[Incident\] Record** action to add a text string to **\[Trigger->Incident Record->Short description\]**.
3.  **Log** action to store the value of the **\[Trigger->Incident Record->Short description\]** data pill.
4.  **Log** action to store the value of the **\[2->Incident Record->Short description\]** data pill.
5.  **Log** action to store the value of the **original-short-description** flow variable.

\[Omitted image "example-data-population.png"\] Alt text: Flow execution details showing the data pill values of the incident short description.

When you test this flow and view it's execution details, you can see that the runtime values reflect the actions and flow logic that were run. Action-1 stores the original incident short description in a flow variable called **original-short-description**. Action-2 changes the value of the **\[Trigger->Incident Record->Short description\]** data pill to add the prefix NEW VALUE: to the front of the string. Any other actions that use this data pill will use this new value. Action-3 logs the current value of the **\[Trigger->Incident Record->Short description\]** data pill, which has been updated by Action-2. Action-4 logs the value of the **\[2->Incident Record->Short description\]** data pill, which has the same value as the **\[Trigger->Incident Record->Short description\]** data pill. Both data pills store the incident short description as set by Action-2. Action-5 logs the value of the **original-short-description** flow variable set by Action-1.

**Important:** Prior to Washington DC release, Workflow Studio populated all data pill values as soon as the data became available regardless of where the data pill was located in the flow sequence. In this example, the Action-3 data pill for **\[Trigger->Incident Record->Short description\]** would be set when the flow starts rather than using the updated the data pill value generated by Action-2. If the older behavior is desired, you can use flow variables to store data pill values as they are generated. For example, Action-1 stores the **\[Trigger->Incident Record->Short description\]**data pill in a flow variable called **original-short-description** before the data pill value is changed.

## Data pill population general guidelines

Flows, subflows, and actions populate data pills when they run, but the timing of when flow components run may effect what data values are used by a flow. Use these guidelines to optimize data pill population.

|Flow component|Example|When data is populated|Usage guidelines|
|--------------|-------|----------------------|----------------|
|Flow trigger record|New incident record|Data is populated when the flow runs|The flow caches the record values gathered when the flow ran. If the flow pauses, then record data can be out of date when the flow resumes.|
|Subflow record input|Reference to an incident record|Data is populated when the subflow runs|Use subflow outputs to pass fresh record data to other actions in the calling flow.|
|Subflow record output \(Wait for completion is true\)|Reference to an updated incident record|Data is populated when the Assign subflow output flow logic is run|The calling flow only uses the data values generated by the subflow.|
|Subflow record output \(Wait for completion is false\)|Reference to an updated incident record|Data is populated when it is first available|If the calling flow already contains the record data in the data cache, the flow uses the cached values.|
|Non-data-gathering action output|Log action|Data is populated when the flow or subflow runs|To avoid stale data, use record data from either a subflow or a data gathering action.|
|Data-gathering action output|Look Up Record action|Data is populated when the action runs|Use the action outputs to pass fresh record data to other actions in the flow.|
|Data-changing action output|Update Record action|Data is populated when the action runs|Use the action outputs to pass fresh record data to other actions in the flow.|

## Data security and HTML sanitation

Workflow Studio protects against cross-site scripting and code injection by evaluating all string data for HTML markup. The system only preserves HTML markup that is present in its inclusion list. All other HTML markup is removed from string data.

The inclusion list supports these HTML elements and attributes, which can't be modified.

|HTML element|Included Attributes|
|------------|-------------------|
|a|class, href, target, title|
|abbr|class, title|
|address|class|
|area|alt, class, coords, href, shape|
|article|class|
|aside|class|
|audio|autoplay, class, controls, loop, preload, src|
|b|class|
|bdi|class, dir|
|bdo|class, dir|
|big|class|
|blockquote|cite, class|
|br|class|
|caption|class|
|center|class|
|cite|class|
|code|class|
|col|align, class, span, valign, width|
|colgroup|align, class, span, valign, width|
|dd|class|
|del|class, datetime|
|details|class, open|
|div|class|
|dl|class|
|dt|class|
|em|class|
|emp|class|
|font|class, color, face, size|
|footer|class|
|h1|class|
|h2|class|
|h3|class|
|h4|class|
|h5|class|
|h6|class|
|header|class|
|hr|class|
|html| |
|i|class|
|img|alt, class, height, src, title, width|
|input|aria-label, class, type, value|
|ins|class, datetime|
|li|class|
|mark|class|
|nav|class|
|ol|class|
|p|class|
|pre|class|
|s|class|
|section|class|
|small|class|
|span|class|
|sub|class|
|sup|class|
|svg|class|
|strong|class|
|style| |
|table|align, border, class, valign, width|
|tag|class|
|tbody|align, class, valign|
|td|align, class, colspan, rowspan, valign, width|
|tfoot|align, class, valign|
|th|align, class, colspan, rowspan, valign, width|
|thead|align, class, valign|
|tr|align, class, rowspan, valign|
|tt|class|
|u|class|
|ul|class|
|video|autoplay, class, controls, height, loop, preload, src, width|