1. Flow Anatomy: Triggers, Conditions & Actions
A Flow (Flow Designer) is built visually from three kinds of blocks: a Trigger (what starts the flow — a record being created/updated, a Service Catalog submission, a schedule), one or more Conditions, and a sequence of Actions (send an email, update a record, create a task, call an Integration Hub spoke) — assembled in a drag-and-drop canvas rather than written as script.
Trigger: Record Created on [incident]
Condition: priority is 1
Actions:
1. Notify [assignment_group manager] via email
2. Create Task on [cmdb_ci.owned_by] — "Verify service impact"
3. Update Record: incident.work_notes += "Escalation flow triggered"
2. Flow Designer vs. Business Rules vs. the Workflow Editor
All three can react to a record change, which makes the choice genuinely confusing at first. A rough, practical guide:
- Business Rule — simple, synchronous, code-level logic tightly coupled to one table's save operation (field validation, defaulting, small immediate side effects). Best when the logic is genuinely just "if this changes, do this small thing," and a developer maintains it.
- Flow Designer — multi-step, often cross-table or cross-system processes that benefit from being visually inspectable and editable by people who aren't primarily developers. Best for anything resembling "when X happens, do this sequence of things," especially involving notifications, approvals, or external systems.
- Workflow Editor — the legacy predecessor to Flow Designer, still present on older instances/processes but not the recommended tool for new automation; Flow Designer is its intended replacement.
ServiceNow's own current guidance steers new multi-step automation toward Flow Designer over both the old Workflow Editor and "do everything in one big Business Rule." Business Rules stay the right tool for small, tightly-scoped, single-table logic — not for orchestrating a multi-step process.
3. Subflows: Reusable Flow Logic
A Subflow is a flow designed to be called from other flows — the flow-level equivalent of Week 6's Script Includes: extract a sequence of actions used in more than one place into its own reusable unit, called with inputs and returning outputs, instead of duplicating the same action sequence across several flows.
4. Integration Hub Spokes
A flow's built-in actions cover ServiceNow-internal operations well, but reaching an external system (Slack, a REST API, an email provider beyond basic notifications) is where Integration Hub spokes come in — pre-built, configurable action packs for specific external systems, dropped into a flow the same way any built-in action is. Where Week 19's Scripted REST APIs are about exposing ServiceNow to the outside world, spokes are largely about consuming outside systems from inside a flow.
5. Hands-on Exercise
Build a P1 escalation flow
Requirements:
- Build a flow triggered on incident record update, with a condition matching "priority changes to 1."
- Add an action appending a note to the incident's work notes announcing the escalation.
- Add a second action creating a Catalog Task (or a simple related record) as a stand-in for a "verify impact" follow-up.
- Test the flow by changing an incident's priority to 1 and confirming both actions ran, using the flow's execution log/history to verify the trigger fired and each action succeeded.
Every flow run keeps an execution log you can open from the flow's related list of Flow Executions — use it to see exactly which trigger fired, which conditions passed, and each action's inputs/outputs, rather than guessing why a flow didn't behave as expected.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
What are the three kinds of blocks a Flow Designer flow is built from?
What are the three kinds of blocks a Flow Designer flow is built from?
A Trigger (what starts the flow — a record change, a catalog submission, a schedule), one or more Conditions gating whether it proceeds, and a sequence of Actions (send an email, update a record, create a task, call an Integration Hub spoke) — all assembled visually rather than written as script.
Q2
When is a Business Rule still the better choice over Flow Designer?
When is a Business Rule still the better choice over Flow Designer?
For simple, synchronous, code-level logic tightly coupled to one table's save operation — field validation, defaulting values, small immediate side effects — maintained by a developer. Flow Designer is the better fit for multi-step, often cross-table or cross-system processes that benefit from being visually inspectable, especially anything involving notifications, approvals, or external systems.
Q3
What is a Subflow, and what pattern from earlier in the course is it analogous to?
What is a Subflow, and what pattern from earlier in the course is it analogous to?
A Subflow is a flow designed to be called from other flows, extracting a reusable sequence of actions into its own callable unit with inputs and outputs. It's the flow-level equivalent of a Script Include (Week 6) — pulling shared logic into one place instead of duplicating it.
Q4
What do Integration Hub spokes add that a flow's built-in actions don't cover on their own?
What do Integration Hub spokes add that a flow's built-in actions don't cover on their own?
Pre-built, configurable action packs for reaching specific external systems (Slack, various REST APIs, other third-party services) — where built-in actions handle ServiceNow-internal operations well, spokes are largely about consuming outside systems from within a flow.