Without understanding approvals and automation, a single purchase request might sit in someone's inbox for three weeks while the manager is on holiday, and nobody would know. Flow Designer and Approvals solve this by letting the system send, track, and escalate approval requests automatically, so nothing gets lost and nothing waits on a person remembering to check their email. For the SNOW-CAD exam, this is the most mechanical and most tested topic — you will see at least five questions on flows, approvals, and how they connect, because this is how real companies automate their most common requests.
Jump to a section
A simple way to picture Flow Designer and Approvals
You live in a flat with three other people. You want to paint the living room bright orange. You have zero budget for this. The landlord is not involved. One flatmate is the 'decoration lead' — they own the paint and the brushes. Before you buy the orange paint, you need that flatmate to say yes. You open your phone, send them a request: 'Can I buy orange paint?' They get a notification. They tap 'Approve' on their phone. The money transfers from the shared flat fund. The paint arrives. Now imagine a bigger request: you want to knock down a wall to open up the kitchen. That needs approval from all three flatmates plus the landlord. You send one request. It gets routed to the landlord first. They approve. Then it goes to flatmate two. They approve. Then to flatmate three. They reject it because the wall is load-bearing. The request stops. No wall-knocking happens. This is exactly how Flow Designer and Approvals work in ServiceNow. A person submits a request for something (orange paint, a new laptop, a week off work). That request triggers a flow — a set of automated steps. The flow sends the request to the right approver (or multiple approvers) in sequence. Each person clicks Approve or Reject. If one says no, the whole thing stops. If everyone says yes, the flow moves forward and does something like creates a purchase order, sends an email, or opens a door in the system. The beauty is it all happens automatically, without anyone manually chasing people down. The number of flatmates in your building could be fifty or five thousand — the flow and approvals system handles it the same way, every time.
The key mapping: the orange paint request is a Record in ServiceNow. The approval request is an Approval record linked to that record. The flow that routes the request is a Flow created in Flow Designer. The flatmate who approves is an Approver (a person or a group). The sequence of who approves first is the Approval Process. And if the request gets rejected, the flow can send a 'Sorry, no orange paint' email automatically. That is the whole system in one flat-sharing analogy.
Flow Designer is a tool inside ServiceNow that lets you build automated processes without writing any code. You drag and drop icons — called 'actions' — onto a canvas to tell the system what to do, step by step. An Approval is a specific kind of action: it sends a request to a person or group asking them to say yes or no to something. The Approval itself is a special record in the database, linked to whatever was submitted (a purchase order, a holiday request, a new hire form).
Every approval in ServiceNow has a state: Pending, Approved, Rejected, or Not Yet Requested. When you submit a request that needs approval, the system creates an Approval record in a Pending state. That record is assigned to an approver — a specific user or an approval group (like 'All IT Managers'). The approver gets a notification (email, text, or a popup in ServiceNow). They click Approve or Reject. The system updates the state. If they approve, the flow can then take the next step — like creating a task, sending a confirmation email, or updating a record. If they reject, the system marks it as Rejected and can trigger a different action, like sending a 'Your request was rejected' notification.
Flow Designer lets you chain multiple approvals in a sequence. This is called a flow. A flow starts when something happens — a trigger. Triggers can be: a record is created (someone submits a new request), a record is updated (someone changes a field), a schedule runs (every Monday at 9 AM), or an API call comes in from another system. Once triggered, the flow runs through steps: check if the requester is a manager (Condition step), send an email to their boss (Action step), wait for approval (Approval step), and if approved, create a task (Action step).
Why does this matter? Before Flow Designer, IT teams had to write scripts or use complex workflow editors to do the same thing. Flow Designer is simpler, faster, and allows non-developers to build processes. For the SNOW-CAD exam, you must understand the flow structure: Trigger, Conditions, Actions, and Approvals. You must also understand how approvals work when there are multiple approvers. ServiceNow supports three approval modes:
Sequential approvals: approver A says yes, then it goes to approver B, then to approver C. If any one says no, the whole chain stops.
Parallel approvals: the request goes to all approvers at the same time. Each one votes yes or no. The result is determined by a rule: all must approve (unanimous), or at least one must approve (any), or a specific percentage must approve.
Group approvals: the request goes to a group like 'IT Managers'. The first person in the group who responds decides. Once someone responds, the approval is closed for everyone else in the group.
Flow Designer also lets you add escalation actions. If an approver does not respond within 48 hours, the flow can automatically resend the notification, escalate to their manager, or even auto-approve or auto-reject based on a rule. This is how companies avoid stalled requests.
Finally, the Approval Engine in ServiceNow is the underlying system that manages all these approval records. It checks who the approver is, what the state is, and what to do next. Flow Designer connects to the Approval Engine every time you use an approval action. The two systems work hand in hand. If you create a flow without an approval action, the flow just automates steps. If you create an approval without a flow, the approval still works but does not trigger any automated actions after approval — someone still needs to manually do the next step. The power is combining them.
For the exam, remember this core rule: Approval records are linked to a parent record. The parent record is the thing being approved (like a purchase order). The approval record has fields for approver, state, comments, and when it was requested. You can report on approvals, create dashboards, and trigger flows based on approval state changes. That is the full picture.
Identify the trigger
Decide what event will start the flow. Common triggers: a record is created (e.g., a new purchase request), a record is updated (e.g., a field changes from Draft to Submitted), or a schedule (e.g., every Monday at 9 AM). For approvals, the trigger is almost always Record Created or Record Updated — when someone submits a request. This matters because without a trigger, the flow never runs.
Add a condition to check before approval
Use a Condition action to decide whether the request needs approval at all. For example: 'If request cost < 100, skip approval and auto-approve'. This prevents unnecessary steps. The condition checks a field value and branches the flow: one path goes to the approval step, the other path skips it. In Flow Designer, you drag a Condition icon onto the canvas and set the rule.
Add the approval action
Drag the Approval action onto the canvas. Configure it: set the Approver (a specific user, a group, or a dynamic field like 'Manager'), set the approval mode (Sequential or Parallel), and set the number of responses needed if parallel. Also set the table: which record is being approved? Usually the same record that triggered the flow. This step creates the Approval record in Pending state.
Add a wait action or set a timeout
After the approval action, add a 'Wait for Approval' action or configure a timeout. The Wait action pauses the flow until someone responds. Without it, the flow would continue immediately and try to do the next step before approval is given. The timeout (escalation) lets you define what happens if no one responds in, say, 2 days: resend notification, escalate to manager, or auto-approve.
Define actions after approval or rejection
Add two branches from the Wait step: one for Approved, one for Rejected. Under the Approved branch, add actions like 'Create Task' (for IT to order the item), 'Send Email' (confirmation to requester), 'Update Record' (set status to Approved). Under the Rejected branch, add actions like 'Send Email' (notification to requester) and 'Update Record' (set status to Rejected). This completes the flow.
Test and publish the flow
Before making the flow live, test it by creating a test record that triggers it. Check that the approval request appears in the correct approver's queue, that the email is sent (if configured), and that the correct actions happen on approval or rejection. Once testing passes, click 'Activate' to publish the flow. An inactive flow does not run. For the exam, remember that flows must be activated to work.
An IT professional at a mid-sized company (500 employees) uses Flow Designer and Approvals to automate their hardware requests. Here is the step-by-step reality.
A marketing manager submits a request in ServiceNow: 'I need a new MacBook Pro for a new hire starting next Monday.' The request creates a Record in the 'Hardware Request' table. This record has fields for requester, item requested, cost, urgency, and start date.
The flow triggers on creation of this record. The flow first checks a condition: Is the cost more than £2,000? If yes, it needs approval from the CFO. If no, it only needs approval from the department head. In this case, the MacBook costs £2,500, so the condition is true. The flow then creates an Approval record assigned to the CFO. The CFO gets an email with a link. The email body is: 'Marketing manager requests a new MacBook Pro at £2,500. Approve or Reject.' The CFO clicks Approve. The Approval record state changes to Approved.
Now the flow continues. The next step is: create a task for the IT procurement team. The task says: 'Order a MacBook Pro for marketing manager's new hire. Budget code: MKTG-2025.' The task is assigned to the procurement team. The flow then sends a confirmation email to the marketing manager: 'Your MacBook request has been approved and is now being ordered.'
But what if the CFO is on leave? The flow has an escalation action: if the approval is still pending after 24 hours, resend the notification. After 48 hours, escalate to the CFO's manager (the CEO). After 72 hours, auto-approve the request. This prevents the request from stalling.
Another scenario: an engineer submits a request for a £50 cable. The flow checks the condition: cost is under £200. So it only needs approval from the department head. But the department head is the same person as the requester (the engineer). The flow has a rule: if the approver is the same as the requester, auto-approve the request. That avoids the absurd situation of someone approving their own tiny purchase.
A third scenario: a request for a new server (£15,000) needs parallel approval from two directors and the CFO. The flow sends it to all three simultaneously. The approval mode is set to 'Unanimous' — all three must approve. The CFO approves, director A approves, but director B rejects because they think the server is unnecessary. The flow marks the overall approval as Rejected. The flow then sends a rejection email to the requester and closes the request.
The IT professional's daily work with this system involves:
Building new flows in Flow Designer when a new business process is defined (e.g., 'Time-off requests now need manager approval plus HR approval').
Testing flows by submitting test requests and checking if the right approvals go to the right people.
Fixing flows when approvers change roles (e.g., CFO leaves, new CFO needs to be in the approval group).
Monitoring the Approval Dashboard to see which requests are pending, who is holding things up, and sending manual reminders if escalation fails.
Adding conditions to flows (e.g., 'If the request is for hardware under £100, skip approval entirely').
Using the 'Approval Rule' feature to change approval behaviour without editing the flow (e.g., change from sequential to parallel for a specific department).
This automation means the IT professional never has to manually forward an email or chase a manager for a signature. The system does it all. For the SNOW-CAD exam, you are tested on whether you understand this flow logic — triggers, conditions, approval modes, and what happens when an approval is rejected or escalated.
The SNOW-CAD exam tests Flow Designer and Approvals heavily — expect 5 to 8 questions on this specific topic area. The questions fall into these patterns:
Flow Designer structure questions: They give you a scenario (e.g., 'A flow should trigger when a change request is submitted. Which trigger type should you use?'). They love testing trigger types: Record Created, Record Updated, Schedule, API. The correct answer is almost always Record Created when the scenario says 'when a record is first submitted'.
Approval mode questions: They describe a situation (e.g., 'Three managers must all approve before a purchase proceeds. Which approval mode?'). The answer is Sequential (if the order matters) or Unanimous Parallel (if all must approve but order does not matter). Be careful: SNOW-CAD uses the term 'Parallel' plus a rule (Unanimous, Any, Percentage). Memorise these exactly.
What happens on rejection: They ask 'If an approver rejects a request in a parallel unanimous approval, what is the state of the overall approval?'. Answer: Rejected. The flow stops. They sometimes try to trick you by asking about the state of the other pending approvals — they are also cancelled.
Escalation actions: They test what triggers an escalation (e.g., 'timeout' or 'duration exceeded') and what the action can do (resend, escalate to manager, auto-approve, auto-reject). The trap is thinking escalation requires a manual action — it does not. The flow handles it automatically.
The difference between an Approval and a Task: Approval asks for a yes/no decision. Task asks someone to do work. They mix these up in questions. Read the scenario carefully: if it says 'needs authorisation', it is an Approval. If it says 'needs someone to perform work', it is a Task.
Specific concepts to memorise:
The five Approval states: Pending, Approved, Rejected, Not Yet Requested, Cancelled. They love testing that 'Cancelled' happens when a parent record is deleted or when a parallel approval is rejected and the other pending ones are cancelled.
Flow Designer components: Trigger, Condition, Action, Approval, Flow Logic (like 'Wait for Approval'). Know that 'Wait for Approval' pauses the flow until someone responds.
Subflows: A flow inside a flow. They test that you can reuse subflows across multiple main flows to avoid repeating steps.
The 'Approval' action in Flow Designer creates an Approval Record. The 'Approval Group' action sends to a group. The 'Set Approval State' action manually changes the state (e.g., from Pending to Approved) without a person clicking. Use this for auto-approvals.
Common traps:
Trap: Non-developers can use Flow Designer. The exam tries to say 'Only developers can use Flow Designer'. That is false. Flow Designer is designed for non-developers. The correct answer is 'Anyone with the right role can build flows'.
Trap: Approvals require an email integration. They do not. Approvals work entirely inside ServiceNow. Emails are optional notifications.
Trap: You cannot have an approval without a flow. False. You can set up an approval rule on a table directly, without any flow. But flows add automation after the approval decision.
Trap: Rejected approvals can be resubmitted. Not automatically. The flow stops. Someone must manually re-submit or a separate flow must handle resubmission.
For the exam, expect one question that shows a screenshot of Flow Designer with specific steps and asks 'Which step is missing?' or 'What will happen next?'. Practise reading flow diagrams. Know that arrows show the sequence. Diamonds are conditions. Rectangles are actions or approvals. The order matters.
Flow Designer is a no-code tool for building automated processes using triggers, conditions, and actions.
Every flow must start with a trigger — the event that causes the flow to run.
An approval action in a flow creates an Approval record, which is separate from the notification email.
ServiceNow supports three approval modes: sequential, parallel (unanimous, any, or percentage), and group.
Rejected approvals stop the flow immediately, cancelling any other pending approvals in that chain.
Escalation actions automatically handle stalled approvals by resending, escalating to manager, or auto-approving after a set time.
Flow Designer is designed for both developers and non-developers — anyone with the right role can use it.
Subflows let you reuse a set of steps across multiple main flows, reducing duplication.
An Approval record can exist without a flow — it is a standalone database record that can be triggered by a manual action or a rule.
A flow can have multiple approval actions, not just one, and they can be combined sequentially and in parallel.
These come up on the exam all the time. Here's how to tell them apart.
Sequential Approval
Approvers respond one after another, in a fixed order.
If any approver rejects, the chain stops and no further approvers see the request.
Useful when approvals depend on previous ones (e.g., manager first, then director).
Parallel Approval
Approvers respond all at the same time.
The overall result depends on the rule: unanimous (all), any (first to respond), or percentage.
Useful when all approvers are independent and their order does not matter.
Flow Designer
Newer tool with drag-and-drop interface, designed for non-developers.
Uses triggers, conditions, and actions in a linear canvas.
Is the focus of the SNOW-CAD exam — all questions reference Flow Designer.
Workflow Editor
Older tool that still works but is not enhanced.
Uses a more complex visual editor with shapes and connectors.
Not tested on SNOW-CAD — but understanding the distinction avoids confusion.
Approval Record
Represents a yes/no decision request (authorisation).
Has states: Pending, Approved, Rejected, Cancelled, Not Yet Requested.
Approver clicks Approve or Reject — no work is done during the decision.
Task Record
Represents a piece of work that needs to be completed.
Has states: Open, Work in Progress, Closed Complete, Closed Incomplete.
Assignee performs actions (ordering, updating, installing) to close the task.
Flow Activation
Making the flow live so it runs on real triggers.
Only active flows execute — inactive flows are ignored by the system.
Requires clicking 'Activate' after the flow is built.
Flow Testing
Running the flow with a test record to check it works correctly.
Allows you to see error messages and fix issues before going live.
Does not require activation — testing can happen on an inactive flow in a test environment.
Mistake
Flow Designer is the same thing as Workflow Editor (the old tool).
Correct
Flow Designer is a different, newer tool that replaced Workflow Editor in recent releases. Workflow Editor still works but is no longer being enhanced. The exam tests Flow Designer, not the old Workflow Editor.
Many study materials from older versions still reference Workflow Editor, leading beginners to confuse the two. The exam explicitly uses Flow Designer in questions.
Mistake
Flow Designer flows run automatically in the background without any trigger.
Correct
Every flow must have a trigger — something that starts it: a record being created, a record being updated, a schedule, or an API call. A flow cannot just exist without something kicking it off.
Newcomers think 'automation' means 'happens by magic'. They do not conceptualise the trigger event. The exam hammers the trigger concept in multiple questions.
Mistake
If I set up an approval in Flow Designer, the request automatically sends an email to the approver.
Correct
The approval itself only creates an Approval record in the database. The email notification is a separate step you must add in the flow. Many flows include a 'Send Email' action before or after the approval, but it is not automatic.
Beginners assume 'approval = notification'. They do not distinguish between the record creation and the notification. The exam tests this separation explicitly.
Mistake
A flow can only have one approval action in total.
Correct
A single flow can have multiple approval actions — sequential, parallel, or mixed. You can have an approval for a manager, then a parallel approval for two directors, then a final approval from the CFO. The flow just has more steps.
Simple examples usually show one approval, so beginners think that is the limit. The exam tests multi-approval flows in longer scenarios.
Mistake
If an approver rejects a request in a sequential approval, the subsequent approvers still get to see and respond to the request.
Correct
When any approver rejects in a sequential flow, the entire flow stops. The approval record state changes to Rejected. The subsequent approvers never get the request. Their pending approvals are automatically cancelled.
People imagine a 'voting' process where everyone gets a say. In ServiceNow, sequential approval stops on first rejection. The exam tests this specifically.
Mistake
Flow Designer can only create flows that involve approvals.
Correct
Flow Designer can automate many other things: sending emails, creating tasks, updating records, calling external APIs, creating PDFs, etc. Approvals are only one type of action among dozens.
Because this chapter focuses on approvals, beginners assume that is the only use. The exam includes questions about non-approval actions (like record creation or update) to test broad knowledge.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Flow Designer is the newer, simpler tool for automation. Workflow is the older tool that still works but is not being updated. Flow Designer uses a drag-and-drop interface, while Workflow uses a more complex visual editor. For SNOW-CAD, focus on Flow Designer.
Yes, absolutely. Flow Designer is designed for non-developers. You select from pre-built actions, conditions, and triggers by clicking and dragging. No JavaScript or scripting is required for basic flows.
In the Approval action configuration, you set the 'Approver' field to a value like 'Record: Manager' (dynamic) or a specific user. For dynamic approvers, use a reference to the requester's manager field from the user profile.
The approval stays in Pending state forever unless you set up an escalation. In the flow, configure a timeout (e.g., 48 hours) and specify what to do — resend the notification, escalate to the approver's manager, or auto-approve/reject.
Yes. You can add multiple Approval actions in a sequence, or use parallel approval to send to several people at once. Each approval action waits for its own response before the flow continues.
An Approval Group is a collection of users classified to receive approval requests. For example, a group called 'CFO-Office' might include three people. When an approval is sent to the group, the first person to respond decides the outcome.
Use the 'Record Updated' trigger type and then add a condition that checks the specific field. For example, 'When Status changes to Submitted and Cost exceeds 500'. The condition filters out irrelevant updates so the flow only runs when needed.
An Approval asks someone to say yes or no (authorise or reject). A Task asks someone to do some work (like order a laptop or update a record). They are different action types in Flow Designer, and both can appear in the same flow.
You've finished Flow Designer and Approvals. Continue through the SNOW-CAD study guide to build a complete picture of the exam.
Done with this chapter?