⚙️ Part 6 · Topic 4 of 4

Flow Designer & Process Automation

⏱ ~65 min read · Self-Service & Automation — 20% Exam Weight

Scope: Flow Designer is ServiceNow's modern no-code/low-code automation platform, introduced in the Paris release. It replaces the legacy Workflow Editor for most use cases. The CSA exam tests understanding of triggers, actions, data pills, subflows, and the distinction between Flow Designer and the legacy Workflow Editor.

Section 1

Flow Designer Overview

Flow Designer is ServiceNow's modern visual automation engine. It allows administrators and developers to build automated processes — without writing code — using a drag-and-drop interface of triggers, actions, and logic blocks.

Core Characteristics

🔁

Modern Replacement

Flow Designer is the modern replacement for the legacy Workflow Editor. While Workflow Editor is still supported, Flow Designer is the preferred tool for all new automation from the Paris release onward.

🖱️

No-Code / Low-Code

Flows are built visually using a point-and-click interface. No scripting is required for common automation patterns, though "Run Script" actions are available for advanced logic.

🖥️

Server-Side Execution

Flows run entirely on the server side — not in the browser. This is a critical exam distinction: unlike Client Scripts, Flow Designer logic executes on the ServiceNow server regardless of how the triggering event occurred.

📋

Storage Table

Flows are stored in the sys_hub_flow table. Navigate to Flow Designer via: Process Automation > Flow Designer or type flow_designer in the Application Navigator filter.

Anatomy of a Flow

Every flow is built from three core building blocks that execute in sequence:

Building Block	Purpose	Example
Trigger	The event that starts the flow running	Record Created on `incident` table
Actions	The individual steps the flow performs	Send Email, Create Record, Ask for Approval
Flow Logic	Controls path — conditional branches and loops	If/Else branch, For Each loop, Wait for Condition

Mental Model: Think of a flow as a recipe. The Trigger is what makes you start cooking (the event). The Actions are the individual steps in the recipe. The Flow Logic is the decision-making ("if no eggs, substitute flax") — branching and looping based on conditions.

Section 2

Flow Components In Depth

Understanding the distinct roles of each component type — and the reusability model — is essential for the CSA exam.

Triggers

A trigger defines what event fires the flow. Only one trigger exists per flow. The trigger also provides the initial data (for example, the triggering record) available to downstream actions.

Actions

Actions are the individual steps that do work. ServiceNow provides a large library of built-in actions. Custom actions can also be created and reused across flows.

Flow Logic

Flow Logic blocks control the execution path within a flow. They do not perform work themselves — they route which subsequent actions will execute.

If / Else If / Else

Evaluates a condition and routes to one of two or more branches. Only the matching branch executes — the others are skipped.

Example: If Priority = 1 (Critical), send a page; Else send a standard email.

For Each

Loops over a list of records returned by a "Look Up Records" action and executes the same set of actions for each item in the list.

Example: For each open child incident, update its state to Resolved.

Wait for Condition

Pauses flow execution until a specified condition becomes true — for example, waiting for an approver to respond before continuing.

Example: Wait until a related task record reaches Closed state.

Data Pills

Data Pills are one of the most important Flow Designer concepts for the exam. They are the mechanism for passing data between steps.

Exam Must-Know — Data Pills: A Data Pill represents the output value of a previous step, made available as an input to a later step. You drag Data Pills from the output of one step and drop them onto the input field of another step. This is how data flows through the flow — you never hard-code values that came from a previous step when a Data Pill is available.

For example: if a "Look Up Record" step finds an incident, the incident's short_description field becomes a Data Pill. You can then drag that pill into the "Subject" field of a "Send Email" action in a later step.

Subflows

Subflows are reusable multi-step sequences that can be called from within a flow or from another subflow. They are stored in the sys_hub_subflow table.

Accept input variables passed in from the calling flow
Return output variables back to the calling flow
Promote reuse — define a sequence once, call it from many flows
Example: a "Create and Assign Task" subflow used across Incident, Change, and Problem flows

Action Types (Reusable Single Steps)

Individual reusable action steps are stored in the sys_hub_action_type table. These are different from subflows — an action type is a single step, while a subflow is a sequence of steps.

Reusable Component	Table	Scope
Subflow	`sys_hub_subflow`	Multi-step reusable sequence; accepts inputs, returns outputs
Action (Action Type)	`sys_hub_action_type`	Single reusable step; the building blocks used inside flows and subflows
Flow	`sys_hub_flow`	Top-level automation; has a trigger; can call subflows and actions

Section 3

Trigger Types

The trigger is the entry point of every flow. ServiceNow provides several categories of triggers to cover most automation scenarios.

Record-Based Triggers

These triggers fire in response to changes on a specific table record. When configuring a record-based trigger, you specify the table and an optional condition that must also be true.

Created

Fires when a new record is inserted into the specified table. Equivalent to a Business Rule set to "on insert."

Updated

Fires when an existing record is modified. You can further filter to fire only when a specific field changes.

Deleted

Fires when a record is removed from the specified table. Useful for cleanup or notification automation.

Created or Updated

Fires on both insert and update. Commonly used when you want the same process to run regardless of whether the record is new or modified.

Other Trigger Types

Trigger Type	When It Fires	Common Use Case
Schedule	At a specified time or interval (daily, weekly, custom cron)	Nightly cleanup jobs, weekly report generation
Application	Triggered programmatically from another flow, subflow, or script	Chain flows together; call a flow from a Business Rule
Inbound Email	When an inbound email is received by the ServiceNow email handler	Auto-create an incident from a support email
Service Catalog	When a catalog item is ordered / submitted by a user	Fulfillment flow for a new laptop request
Condition	When a defined condition evaluates to true on a record	Escalate P1 incidents open more than 30 minutes

Exam Distinction — Trigger Condition vs. Flow Logic If/Else: The trigger condition determines whether the flow even starts (it is evaluated before the flow runs). The If/Else logic block controls which path the flow takes after it has already started. Do not confuse these two — the trigger decides "should this flow run?", If/Else decides "which branch should it follow?"

Section 4

Built-in Actions

ServiceNow ships with an extensive library of built-in actions covering the most common automation tasks. These can be used directly inside any flow or subflow without additional configuration.

Record Management Actions

Create Record

Inserts a new record into any table. You specify the table and set field values — either hard-coded or via Data Pills from earlier steps.

Update Record

Modifies an existing record. You supply the record (typically from a Data Pill) and specify which fields to change and what to set them to.

Delete Record

Removes a record from a table. Use with care — typically combined with a condition or approval to prevent accidental deletions.

Look Up Record

Finds a single record matching a specified condition. Returns the record as a Data Pill for use in later steps.

Look Up Records

Finds multiple records matching a condition. Returns a list that can be iterated with a "For Each" logic block.

Notification & Communication Actions

Send Email

Sends an email notification. You can use Data Pills to dynamically populate the recipient, subject, and body from earlier step outputs.

Create Task

Creates a Task record (or subclass) and assigns it to a user or group, with configurable due dates and descriptions.

Log

Writes a message to the flow execution log. Invaluable for debugging — you can log variable values at key points in the flow.

Approval Actions

Ask for Approval

Sends an approval request to a single approver or a group. The flow pauses and waits for a response before proceeding. Outcomes: Approved, Rejected, or Cancelled.

Request Approval

A more configurable approval action that supports complex approval rules — multiple approvers, voting thresholds, and sequential approval stages.

Utility Actions

Wait for Condition

Pauses the flow until a field on a record meets a condition. The flow is suspended (not blocking a thread) and resumes when the condition is satisfied.

Set Flow Variables

Assigns values to flow-level variables for use in later steps. Useful for storing computed or looked-up values that will be referenced multiple times.

Section 5

Flow Variables

Flow Designer uses variables to store, pass, and return data at different scopes within the automation. Understanding each variable type is important for designing well-structured flows.

Variable Type	Scope	Direction	Use Case
Input Variables	Flow or Subflow	Passed into the flow at trigger time	Accept parameters from the caller — e.g., a sys_id passed to a subflow
Output Variables	Subflow	Returned from subflow back to calling flow	Return a created record's sys_id back to the parent flow
Flow-level Variables	Flow	Internal to the flow's execution	Store intermediate values (e.g., a counter, a looked-up sys_id) for reuse later in the same flow

Legacy Comparison — Scratchpad: In the legacy Workflow Editor, a Scratchpad object was used to pass values between Activity steps within a workflow. In Flow Designer, this role is played by Flow-level Variables and Data Pills. When you see "scratchpad" on the exam, it refers to the legacy Workflow Editor concept.

Best Practice: Prefer Data Pills over flow-level variables when the data you need is the direct output of a preceding step. Use flow-level variables when you need to compute a value that will be referenced by multiple downstream steps, or when you need to accumulate data across loop iterations.

Section 6

Approval Actions in Detail

Approval automation is one of the most common enterprise use cases for Flow Designer. Understanding how approvals are structured and stored is directly tested on the CSA exam.

How Ask for Approval Works

Flow reaches the "Ask for Approval" action step
ServiceNow creates approval records in the sysapproval_approver table
The flow pauses execution and waits — it is not blocking server resources; it suspends elegantly
The approver receives a notification and takes action (Approve, Reject, or Cancel)
The flow resumes and continues down the Approved, Rejected, or Cancelled outcome branch

Approved Outcome

The approver clicked Approve. Flow continues on the Approved branch — typically to fulfill the request or progress the record.

Rejected Outcome

The approver clicked Reject. Flow routes to the Rejected branch — typically to notify the requester and close or cancel the item.

Cancelled Outcome

The approval was cancelled programmatically or by admin action. Flow routes to the Cancelled branch for appropriate handling.

Key Exam Fact — Approval Table: Approval records created by the "Ask for Approval" action are stored in the sysapproval_approver table. Each approver gets one record. The state of that record (Approved / Rejected / Cancelled) is what drives the flow outcome.

Catalog Item Approvals

When a Service Catalog item is ordered, Flow Designer handles the fulfillment process including approvals. The flow is triggered via the Service Catalog trigger, and "Ask for Approval" steps enforce manager or group approval before provisioning begins. This replaces the legacy catalog workflow.

Section 7

Flow Designer vs. Workflow Editor

This comparison is directly tested on the CSA exam. Both tools automate processes, but they differ significantly in design philosophy, interface, and capabilities.

Aspect	Flow Designer	Workflow Editor (Legacy)
Introduced	Paris release (2020) and later	Much older — pre-2018 platform
Interface	Modern sequential step-list UI	Flowchart-style canvas with drag-and-drop nodes
Data Passing	Data Pills — visual drag-and-drop from step outputs	Scratchpad variables — manual coding required
Code Required	No-code/low-code — scripting is optional	Many activities require Jelly scripting or JavaScript
Storage Table	`sys_hub_flow`	`wf_workflow`
Reusability	Subflows (`sys_hub_subflow`) and Actions (`sys_hub_action_type`)	Sub-workflows — less flexible reuse model
Testing	Built-in "Test" button — runs without triggering real records	Requires manual record manipulation to test
Execution Logging	Detailed per-step execution log viewable in Flow Designer	Less granular logging; harder to debug
IntegrationHub	Full native support — spoke actions callable directly	Limited / no direct spoke support
Status	Preferred — all new automations should use this	Supported but legacy — not recommended for new builds

When Workflow Editor Is Still Needed: Some older features — particularly certain Service Catalog configurations, legacy SLA workflows, and custom Activities built before Flow Designer existed — may still rely on the Workflow Editor. Administrators must understand both tools. However, for the CSA exam, the default answer for "which tool should you use for new automation?" is always Flow Designer.

Section 8

Error Handling & Debugging

Flow Designer provides built-in mechanisms to handle errors, test flows safely, and diagnose problems when flows fail in production.

Flow Execution Log

Every time a flow runs, ServiceNow records a detailed execution log showing the result of each individual step. Access it via:

Process Automation > Flow Designer > [open a flow] > Executions tab

Shows each step: name, status (Success / Error), inputs used, outputs produced
Log messages written via the Log action appear here — valuable for debugging data pill values
Failed steps are clearly highlighted with error details

Failed Flows — Options

Resume

After fixing the underlying problem (e.g., correcting data, fixing a script), you can resume a failed flow execution from the point of failure — no need to re-run from the beginning.

Cancel

Permanently terminates a failed or stuck flow execution. Use this when the flow should not be retried — for example, if the triggering record no longer exists.

Error Trigger

A special trigger type that fires when another flow encounters an error. Use it to build centralized error-handling flows — for example, creating an incident when a critical automation fails.

Testing Flows Safely

Built-in Test Mode: Flow Designer includes a Test button on every flow. This allows you to run the flow against a real (or specified) record in a controlled way — without waiting for the actual trigger event to fire. Test mode shows the execution log in real time, making it straightforward to verify each step's behavior before activating the flow.

Section 9

Integration with Other ServiceNow Tools

Flow Designer does not operate in isolation — it integrates with Business Rules, Client Scripts, Catalog, and IntegrationHub to form a complete automation ecosystem.

Integration Point	How They Connect
Business Rules → Flow	A Business Rule can fire a Flow Designer flow programmatically using `gs.eventQueue()` or by triggering an Application trigger event. This bridges record-level server scripts with the flow automation layer.
Flow → Script Includes	Within a flow, the "Run Script" action can instantiate and call a Script Include class. This allows complex business logic housed in reusable Script Includes to be called from a no-code flow.
Catalog Items → Flow	Service Catalog items can use a flow (via the Service Catalog trigger) as their fulfillment process, replacing the legacy catalog workflow. The flow receives catalog variables as inputs.
Approvals	Flow Designer handles multi-stage approvals natively via "Ask for Approval" and "Request Approval" actions, writing to `sysapproval_approver` and routing based on outcomes.
IntegrationHub	IntegrationHub adds "Spoke" action packs (Slack, Jira, ServiceNow, REST, etc.) that appear as draggable action steps inside Flow Designer. Flows can call external APIs with no scripting required.

The Modern Automation Stack: In a well-architected ServiceNow instance, the automation layers work together: Client Scripts handle real-time form behavior in the browser → Business Rules enforce server-side record logic → Flow Designer orchestrates multi-step processes and integrations → IntegrationHub extends flows to external systems. Each tool has its lane.

Section 10

Key Exam Facts & Quick Reference

These are the highest-frequency exam points for Flow Designer. Review these carefully before your exam.

Fact 1 — Data Pills: Data Pills are the outputs of previous steps, made available as drag-and-drop inputs to later steps. They are how data flows through a flow without hardcoding. A Data Pill is NOT a variable — it is a reference to the live output of another step.

Fact 2 — Subflows vs. Actions: A Subflow (sys_hub_subflow) is a reusable multi-step sequence. An Action (sys_hub_action_type) is a reusable single step. Both can accept inputs and return outputs. Subflows are used when you need to share a multi-step process; Actions when you need a single reusable step.

Fact 3 — Server-Side Execution: Flow Designer runs entirely on the server, not in the browser. This distinguishes it from Client Scripts (which run in the browser). A flow will execute even when records are modified via REST API, import sets, or background scripts — not just through the UI.

Fact 4 — Trigger vs. If/Else: The trigger condition determines whether the flow fires at all. The If/Else logic block controls the execution path after the flow has already started. These are evaluated at different times and serve different purposes.

Fact 5 — Ask for Approval Pauses Execution: The "Ask for Approval" action causes the flow to suspend and wait for the approver's response. Approval records are stored in sysapproval_approver. The three possible outcomes that drive subsequent branching are: Approved, Rejected, Cancelled.

Fact 6 — Execution Logs: Flow execution history and per-step logs are accessible via Process Automation > Flow Designer > [flow] > Executions. Failed executions can be resumed (not just retried from scratch).

Fact 7 — Paris Release Requirement: Flow Designer requires the Paris release or later. If an exam question describes a pre-Paris instance, the Workflow Editor would be the automation tool in use.

Tables Quick Reference

sys_hub_flow

Flows — top-level automation with triggers

sys_hub_subflow

Subflows — reusable multi-step sequences

sys_hub_action_type

Action types — reusable single steps

sysapproval_approver

Approval records created by Ask for Approval

wf_workflow

Legacy Workflow Editor workflows

🎓

You Have Completed the Entire CSA Study Course!

This is the final topic of all six parts. You have worked through every major domain of the ServiceNow Certified System Administrator exam — from platform navigation and configuration, through collaboration and database security, migration and integration, all the way to self-service and automation.

That is a substantial body of knowledge. Give yourself credit for the effort you have put in.

Recommended next steps before exam day:

Review the flashcards for all six parts — reinforce the key terms and tables
Revisit any topics where you felt less confident — especially ACLs, Data Pills, and Business Rules
Work through the practice quizzes for each part and review every wrong answer
Re-read the "Exam Traps" and "Key Exam Facts" sections across all topics — these are where exam marks are most commonly lost
On exam day: read each question stem carefully. ServiceNow exam questions often hinge on one precise word (server-side vs. client-side, table ACL vs. field ACL, trigger condition vs. flow logic). Take your time.

You are prepared. Go earn that certification.

← Client Scripts Back to CSA Hub