# Workflow and Flow Designer

> Chapter 10 of the Courseiva SERVICENOW-CSA curriculum — https://courseiva.com/learn/servicenow-csa/workflow-and-flow-designer

**Official objective:** 3.1 — Design and manage workflows and flow designer flows for process automation.

## Introduction

If you cannot automate the handoffs between people and systems, your IT department will drown in repetitive manual tasks—resetting passwords, approving requests, provisioning software—and users will wait days for things that should take minutes. Workflow and Flow Designer are the core tools in ServiceNow that let you design these automatic sequences, so you can pass the SNOW-CSA exam and prove you know how to make an IT team run efficiently without adding headcount.

## The Coffee Shop Order Fulfilment Analogy

You walk into a busy coffee shop at 8:15 AM. 15 people are ahead of you. The barista writes your order on a paper cup with a marker. If the shop uses a manual system, that cup is passed from person to person. One person might forget to add the extra shot, another might steam the wrong milk, and a third might put the cup on the wrong counter. Every mistake means a remake, a delay, and a grumpy customer.

Now imagine the shop uses a Flow Designer. When you order, a digital ticket is created. That ticket automatically checks: what drink? Any customisations? Is the milk in stock? It then triggers a sequence: label the cup, queue the espresso machine, alert the barista when the shot is ready, and then hold the finished drink in a warm zone until you collect it. If the oat milk runs out, the flow pauses and sends the manager a notification to restock before the next customer orders. No sticky notes. No one shouting 'I forgot the caramel!' Every step is guaranteed to happen in the right order, every time.

That digital sequence—the automatic steps that turn a request into a completed job—is exactly what a Workflow or a Flow does in ServiceNow. The Flow Designer is the tool you use to build those sequences, like programming the coffee shop's entire morning rush into a reliable, repeatable robot.

## Core explanation

In ServiceNow, a Workflow (often called a 'Legacy Workflow') and a Flow (built in Flow Designer) are two ways to automate a series of steps that must happen in a specific order. Think of them as recipes for a computer to follow. Each recipe starts with a trigger—something that starts the process, like a user submitting a request or a record being created. Then it follows a set of actions: maybe it sends an email, waits for a manager's approval, updates a database field, or creates a new record. Finally, it ends when the goal is achieved, such as a password being reset or a laptop being ordered.

Workflow was the original automation tool in ServiceNow. It is a visual, drag-and-drop designer where you connect boxes representing steps. Each box might be a 'Task' (something a human does), an 'Approval' (waiting for someone to say yes or no), a 'Timer' (waiting a set amount of time), or a 'Condition' (checking if a value is true or false and branching accordingly). Workflows are powerful but older, and they can be harder to maintain because the design interface is less intuitive and the logic is often spread across many tabs. They also run on a separate engine called the Workflow Engine, which can be slower.

Flow Designer is the modern replacement. It was introduced to make automation easier, faster, and more visual. A Flow is also a sequence of steps, but the interface is cleaner and more structured. You build a Flow using three main parts: a Trigger (what starts the flow—like 'Record Created' or 'Scheduled'), Conditions (filters that decide if the flow should run, like 'only if the category is Hardware'), and Actions (what the flow actually does, like 'Update Record', 'Send Email', or 'Create Record'). Flow Designer also supports Subflows, which are reusable sets of actions you can call from multiple flows, just like a reusable recipe you use for different meals.

Why does this matter? Before automation, every request required a human to read the details, decide the next step, perform the action, and then notify the requester. This is slow and error-prone. With Workflow and Flow Designer, these steps happen automatically, in milliseconds, without anyone lifting a finger. For example, when an employee fills out a 'New Laptop Request' form, a Flow can: (1) check the employee's department, (2) create a hardware asset record, (3) send a purchase order to the procurement team, (4) update a ticket with the estimated delivery date, and (5) email the employee confirmation—all without a human touching the process.

Flow Designer also integrates with other ServiceNow features like Visual Task Boards (a Kanban-style board for tracking work) and Spoke integrations (pre-built connections to external systems like Slack, Jira, or Microsoft Entra ID). A Spoke is a package of actions that talk to a specific external service—for example, a 'Microsoft Teams Spoke' has actions like 'Send Message' or 'Create Channel'. This means you can automate processes that cross multiple tools, not just ServiceNow itself.

The key difference between Workflow and Flow Designer is that Workflow is an older, more limited tool being phased out, while Flow Designer is the current and future direction. The SNOW-CSA exam expects you to know both exist, but to focus heavily on Flow Designer—its components (Triggers, Conditions, Actions, Subflows), how to test a flow using the 'Test' button, and how to activate/deactivate flows. You will also need to know that Workflows use 'Activities' (the boxes) and that they are associated with specific tables (like 'Change Request' or 'Incident'), whereas Flows can be triggered by records, schedules, or even incoming webhooks from external apps.

## Real-world context

Let us walk through a real scenario: a mid-sized company with 500 employees uses ServiceNow to manage IT requests. Their employees submit tickets through a service portal when they need a new software licence, like Adobe Photoshop. Without automation, an IT support agent would receive the ticket, manually check if the employee's manager has approved the budget, verify if a licence is available, install the software, and then close the ticket—taking roughly 45 minutes per request. With a Flow Designer flow, the entire process can be automated.

Here is the step-by-step flow the IT team would build:

- Trigger: The flow starts when a new record is created in the 'Request' table with a category of 'Software Licence'.
- Condition: The flow only proceeds if the 'Cost' field is less than $500. If it is more, the flow branches to a separate approval path that requires the IT director's sign-off.
- Action: The flow creates a 'Hardware Software Request' subflow, which first checks the 'Software Asset' table to see if there are unused licences. If a licence exists, it reduces the count by one. If not, it sends an email to the procurement team to buy one.
- Action: The flow sends an automated email to the employee's manager with a link to approve the request. It waits up to 48 hours for the approval. If approved, it continues; if denied, it sends a rejection email and closes the ticket.
- Action: The flow updates the original ticket status to 'In Progress' and assigns it to the software distribution team (but only if they are within their working hours—otherwise, the flow holds until the next business day).
- Action: Once the installation is confirmed (by a technician updating a custom field), the flow sends a satisfaction survey, updates the ticket to 'Resolved', and logs the time taken in a metrics table.

What does the IT professional actually do? They use Flow Designer to drag and drop these steps, configure each action's properties (like which email template to use or which field to update), and then test the flow using the built-in 'Test Flow' feature. They also monitor the 'Flow Logs' to see if any flow failed—for example, if a mandatory field was missing or an external system was down. They can even set up 'Flow Triggers' based on schedules, like a daily flow that checks all open requests older than a week and escalates them to a manager.

The real benefit is that the IT team no longer spends hours on routine requests. They can focus on complex problems, while the flow handles the predictable, repetitive parts. This is exactly why companies adopt ServiceNow—and why the SNOW-CSA exam tests your ability to design and manage these automations.

## Exam focus

The SNOW-CSA exam tests Workflow and Flow Designer in several specific ways. You must understand the core components and the differences between the old and new systems. Here is what to expect:

Question types:
- Multiple-choice questions asking you to identify the correct component for a situation. For example: 'Which component in Flow Designer determines whether a flow should execute based on specified criteria?' The answer is 'Conditions'.
- Drag-and-drop questions where you order the steps of a flow (Trigger, Condition, Action, Conclusion).
- 'Choose the best tool' questions: 'Should you use Workflow or Flow Designer to automate a process that needs to integrate with Microsoft Entra ID?' Answer: Flow Designer, because it supports spokes.
- True/false questions about specific features, such as 'Subflows can be called from multiple flows.' This is true.

Key concepts they love to test:
- The difference between a Workflow (uses Activities, runs on Workflow Engine) and a Flow (uses Actions, runs on Flow Engine).
- The three parts of a Flow: Trigger, Condition, Action.
- The types of triggers: Record (created, updated, deleted), Scheduled (at a certain time/day), and Webhook (incoming HTTP request).
- How to test a flow: using the 'Test Flow' button in Flow Designer, which runs the flow in a sandbox and shows you the output of each step.
- The concept of a 'Subflow': a set of actions that can be reused and passed parameters; they are like a function in programming.
- The 'Flow Logs' table (sys_flow_context): where you can see the history of every flow execution, including success, failure, and any error messages.

Common traps and how to avoid them:
- Trap: Confusing 'Conditions' with 'Triggers'. Remember: the trigger starts the flow; the condition filters whether the flow runs given that trigger. A trigger is like a door opening; a condition is a bouncer who decides if you can enter.
- Trap: Thinking Workflow is still the recommended tool. The exam is biased toward Flow Designer. If a question asks 'Which tool should you use for a new automation?', the answer is almost always Flow Designer.
- Trap: Forgetting that Subflows can have input and output parameters. They are not just glorified actions; they can accept data, process it, and return results.
- Trap: Assuming every flow runs immediately. Scheduled triggers run at the specified time; record triggers run after the record is saved. There is no 'instant' trigger outside of a test.
- Trap: Mistaking 'Flow' for 'Workflow' when the question mentions 'Legacy'. Legacy always refers to Workflow.

To memorise: Know that a Flow is activated by toggling 'Active' to true in the Flow Designer header. Know that you can deactivate a flow and it will stop responding to triggers. Study the icons: a flow icon looks like a lightning bolt with a circle, while a workflow icon looks like a flowchart with boxes and arrows. The exam loves asking about the 'Flow Designer' interface, including the 'Action' palette on the left side and the canvas in the centre.

## Step by step

1. **Identify the Process** — Determine which business process needs automation, such as 'approve and provision new software licences'. Write down the steps a human would take, including all decision points. This is your blueprint.
2. **Choose the Trigger** — Decide what event starts the flow: a new record being created (Record trigger), a time-based schedule (Scheduled trigger), or an incoming API call (Webhook trigger). This is the 'when' of the automation.
3. **Add Conditions** — Filter the trigger so the flow only runs under specific circumstances. For example, 'only if the category equals Software'. Conditions prevent the flow from running on irrelevant records, saving resources.
4. **Configure Actions** — Drag and drop actions from the palette onto the canvas. Common actions include 'Update Record', 'Send Email', 'Create Record', and 'Wait for Approval'. Link them in sequence or use parallel branches for simultaneous tasks.
5. **Test and Activate** — Use the 'Test Flow' button to simulate the flow with sample data. Check the output log for each action. If it works correctly, toggle the 'Active' switch to 'true' to let the flow run in the live environment.

## Comparisons

### Workflow (Legacy) vs Flow (Flow Designer)

**Workflow (Legacy):**
- Uses Activities (boxes) dragged onto a canvas
- Runs on the Workflow Engine
- Cannot integrate with external spokes without custom code

**Flow (Flow Designer):**
- Uses Triggers, Conditions, and Actions
- Runs on the Flow Engine (faster and more scalable)
- Supports Spokes for easy integration with external systems like Slack or Microsoft Entra ID

### Record Trigger (Flow) vs Scheduled Trigger (Flow)

**Record Trigger (Flow):**
- Starts when a record is created, updated, or deleted
- Runs immediately after the database change
- Common use: automating a response to a new ticket

**Scheduled Trigger (Flow):**
- Starts at a specific time (e.g., daily at 5 PM)
- Runs on a timetable, not on user actions
- Common use: nightly cleanup of stale records

### Action vs Subflow

**Action:**
- A single step in a Flow (e.g., Send Email)
- Cannot accept input parameters (built-in behaviour)
- Cannot be called from other flows

**Subflow:**
- A reusable collection of actions
- Accepts input parameters and can return output
- Can be called from multiple parent flows

### Flow Designer vs Workflow Editor

**Flow Designer:**
- Modern drag-and-drop interface
- Has a built-in test mode that is non-destructive
- Integrates with visual task boards and spokes

**Workflow Editor:**
- Older, more complex interface
- Testing requires building a test playbook manually
- Limited to ServiceNow-native actions

## Diagram

_This shows the structure of a Flow in Flow Designer: a trigger starts the process, a condition filters it, and then actions execute sequentially based on the decision branch._

```mermaid
flowchart TD
    T[Trigger: Record Created] --> C{Condition: Category == Software?}
    C -- Yes --> A1[Action: Check Licence Availability]
    A1 --> A2[Action: Send Approval Request to Manager]
    A2 --> A3{Wait for Approval}
    A3 -- Approved --> A4[Action: Assign Licence]
    A4 --> A5[Action: Send Confirmation Email]
    A5 --> END[End]
    A3 -- Rejected --> A6[Action: Send Rejection Email]
    A6 --> END
    C -- No --> END
```

## Common misconceptions

- **Misconception:** Workflow and Flow Designer do the exact same thing, so I only need to learn one. **Reality:** They both automate processes, but Flow Designer is the modern replacement. Workflow is legacy and being phased out. The exam tests both, but focuses on Flow Designer. (Beginners see both tools listed under automation and assume they are interchangeable. They do not realise Workflow is older and less capable, which leads to wrong answers when the exam asks about recommended tools.)
- **Misconception:** A Flow runs instantly when someone clicks a button because it is 'automated'. **Reality:** Flows run after a trigger condition is met, not instantly on a button click unless you set up a specific UI Action or a Catalog Task. Most flows run after a record is saved or on a schedule. (The word 'automation' gives a false sense of immediacy. Beginners imagine a flow works like a script that runs in real-time, but the flow engine processes triggers in batches and at specific times.)
- **Misconception:** Subflows are just smaller flows and you can share them like you share bread recipes. **Reality:** Subflows are reusable sets of actions within a flow. They must be designed with input parameters because they receive data from the parent flow. They are not standalone flows and cannot have their own triggers. (Because they are called 'subflows', beginners assume they are just miniature flows. They miss the key distinction: a subflow cannot start on its own; it must be called from another flow or subflow.)
- **Misconception:** The Test Flow feature runs the flow for real, so you should use it cautiously in production. **Reality:** The Test Flow feature runs the flow in a sandbox—a safe, isolated environment. It does not affect real data or trigger other processes. It is safe to use anytime to verify behaviour. (People confuse 'test mode' with 'simulation' and worry about breaking things. The exam loves to test this misconception. The correct answer is that Test Flow is non-destructive.)
- **Misconception:** Legacy Workflows are completely removed from ServiceNow, so you should ignore them. **Reality:** Legacy Workflows still exist in many instances and may be present in existing customers' environments. The exam expects you to know they exist, but not to design new ones. You should know they use Activities and have a separate engine. (Since Courseiva and other study guides emphasise Flow Designer, beginners assume Workflows are obsolete. But the exam includes questions about Workflows to see if you recognise legacy concepts.)

## Key takeaways

- Flow Designer is the recommended tool for building process automation; Workflow is the legacy tool that you should only maintain, not create new ones.
- A Flow has three required parts: a Trigger (what starts it), Conditions (filters for execution), and Actions (what it does).
- Subflows are reusable action sets that can receive input parameters and return outputs, but they cannot be triggered on their own.
- Use the 'Test Flow' button to safely run a flow in a sandbox without affecting live data.
- Flow Logs (sys_flow_context) record every flow execution, showing success, failure, and error messages for debugging.
- You can activate or deactivate a flow using the 'Active' toggle; deactivated flows ignore all triggers.
- When the exam asks 'Which tool should you use for a new automation?', the correct answer is always Flow Designer.
- A flow can have multiple triggers, but a Subflow cannot—it must be called from a parent flow.

## FAQ

**What is the difference between a Workflow and a Flow in ServiceNow?**

A Workflow is the older automation tool using Activities and running on the Workflow Engine. A Flow is the modern replacement built in Flow Designer, using Triggers, Conditions, and Actions, and running on the Flow Engine. Flow Designer is recommended for all new automations.

**Can I reuse a Flow in multiple places?**

Yes, by creating a Subflow. A Subflow is a set of actions you can call from different parent flows. You can pass input data to it and receive output data back, making it reusable like a function.

**How do I test a Flow without affecting real data?**

Use the 'Test Flow' button in Flow Designer. It runs the flow in a sandboxed environment, showing you the results of each action without changing your production data or triggering other processes.

**What triggers can a Flow have?**

A Flow can have a Record trigger (created, updated, deleted), a Scheduled trigger (time-based, e.g., daily at 8 AM), or a Webhook trigger (receiving an HTTP request from an external system).

**What happens if a Flow fails?**

The flow execution is recorded in the Flow Logs table (sys_flow_context) with an error message. You can view the logs in Flow Designer or navigate to 'Flow Logs' in the ServiceNow menu to see the cause of failure and retry or fix the flow.

**Do I need to know coding to use Flow Designer?**

No. Flow Designer is a low-code tool with a drag-and-drop interface. You can build automations using pre-built actions and logic blocks. Some advanced functionality might require scripts, but the SNOW-CSA exam focuses on the graphical interface only.

**Can a Flow be used to approve requests?**

Yes. You can use an 'Approve' action (or 'Wait for Approval') within a Flow. This sends a notification to the approver and pauses the flow until a decision is made, then continues based on whether it was approved or rejected.

## Check your understanding

1. **What are the three required parts of a Flow in Flow Designer?**

   Answer: A Trigger (what starts the flow), Conditions (filters for execution), and Actions (what the flow does).

2. **You need to reuse a set of actions across multiple flows in a ServiceNow instance. Which component should you build?**

   Answer: A Subflow.

A Subflow is a reusable set of actions that can be called from any flow.

3. **True or False: The 'Test Flow' feature in Flow Designer runs a flow using real production data.**

   Answer: False.

The Test Flow feature runs the flow in a sandboxed environment and does not affect live data.

4. **A legacy automation in ServiceNow uses 'Activities' and runs on the Workflow Engine. Is this a Workflow or a Flow?**

   Answer: This is a Legacy Workflow.

Workflows use Activities and run on the Workflow Engine, while Flows use Triggers, Conditions, and Actions on the Flow Engine.

5. **If you want a Flow to only run when the 'Priority' field equals 'High', which part of the Flow do you configure?**

   Answer: The Conditions section.

Conditions filter the trigger so the flow executes only for records that meet the specified criteria.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-csa/workflow-and-flow-designer