Workflow Automation CoE > Playbooks > Building Dynamic Playbooks > Part 1: Overview and Conditional Activities
Four Patterns You Should Know
Goal
This is the first article in a four-part Workflow Automation Center of Excellence series on building dynamic playbooks in Workflow Studio. This article introduces four adaptive design patterns, conditional activities and stages, decision-based branching (decision activities and decision stages), playbook variants, and nested playbooks, and points you to a dedicated deep dive article for each remaining pattern. It then walks through the first pattern, conditional activities, in full, using a realistic Knowledge Management (KM) scenario. Every article in the series uses the same running KM scenario so you can see exactly when and why you'd reach for one feature over another.
Technology
Workflow Studio is our central, low code workflow automation builder that consolidates flow, subflow, playbook, decision table, and action design into a single environment.
To build adaptive Knowledge Management playbooks across this series, we'll use these product features:
|
Product/Feature |
Description |
|
End-to-end process automation with a guided user experience layered on top of subflows or flow actions |
|
|
UI framework that surfaces playbook stages and activities to agents and fulfillers within various user experiences like workspaces and portals |
|
|
or (Run condition) |
A stage or activity property that determines whether that stage or activity executes at runtime, based on a condition |
|
Branching paths between activities within a stage or between stages, driven by conditions, showing only the relevant path at runtime |
|
|
Condition-based variations that modify activities within a shared stage structure |
|
|
Standalone child playbooks embedded in a parent, functioning like subflows for playbooks |
|
|
AI agents embedded within playbook activities to automate data gathering and form filling |
Instructions
Why Playbooks for Knowledge Management?
Before we dive in, let's address a top-of-mind question: why use playbooks instead of flow automation for Knowledge Management?
Flows are great when the process runs entirely in the background: auto-routing, auto-updating fields, sending notifications. But Knowledge Management processes almost always involve a human in the loop. Someone needs to draft the article, review the content, make a judgment call about quality, or triage incoming feedback. That's exactly where playbooks shine.
Playbooks give your knowledge workers a guided experience through Playbook Experience in Workspaces, Service Portal, the ServiceNow mobile app, or Employee Center. Agents see the current stage, the activities they need to complete, and the decisions they need to make, all in context. You don't have to build custom UI, the playbook renders it for you.
Meet the Four Patterns
Each pattern below gets full treatment somewhere in this series. Here's the short version of each, so you can jump straight to the one you need.
- Conditional stages or activities. A knowledge worker creates a new article from a resolved incident. The core process (draft, review, publish) is always the same, but individual stages or steps, like a compliance check for external articles or an attachment review, should only run when certain conditions are met. Conditional activities let you skip or include individual steps without changing the overall playbook shape and conditional stages do the same for a full stage. A single toggle like this can also be modeled as a two-branch decision (condition matches, or not); the use case below shows both forms side by side so you can see the trade-off directly. Covered in full below, in this article.
- Decision-based branching: decision activities and decision stages. These serve the same underlying pattern: a conditions-driven fork, applied at two different scopes. When someone flags a knowledge article as inaccurate, the knowledge manager needs to triage it: quick fix, send to a subject matter expert, or dismiss. Each path involves different work, but it all happens within one "Triage" stage, so a decision activity gives the agent an explicit choice that routes to different activity paths within that same stage. When an article moves into Review, the review process it needs depends on its risk level: a fast track for low-risk internal articles, a standard review with approval for external facing ones, and a full compliance review for regulated knowledge bases. These aren't different activities within one stage, they're entirely different stages, so a decision stage routes to one of several downstream stages based on conditions, and only the relevant stage appears to the agent.
Read Part 2: Decision Activities and Decision Stages »
- Playbook variants. An organization with IT, HR, and Legal knowledge bases wants the same three stage process (Draft, Review, Publish) for all of them, but each knowledge base needs its own extra steps: a duplicate check for IT, a PII checklist for HR, a disclaimer and dual approval for Legal. Variants let you override activities and add extra ones per stage, all from a single base playbook that automatically applies the matching variant at runtime.
Read Part 3: Playbook Variants »
- Nested playbooks. A standard content quality review, checklist, quality score, pass or fail decision, needs to run in three different contexts: initial article creation, periodic maintenance, and feedback driven updates. Rather than duplicating that logic three times, you build it once as a standalone child playbook and embed it wherever it's needed. Changes propagate automatically to every parent that uses it.
Read Part 4: Nested Playbooks »
Quick Reference: Which Pattern Do I Need?
|
If your requirement is... |
Use this pattern |
|
Individual steps or stages that run or skip based on conditions, and you don't need the branch visible on the canvas |
Conditional activities or stages (Run condition) |
|
The same skip or include logic, but you want it visible on the canvas as an explicit branch |
Decision activities |
|
Entirely different stages based on conditions |
Decision stages |
|
Same stages, different activities per category |
Playbook variants |
|
Reusable process segments shared across playbooks |
Nested playbooks |
Note: conditional activities and decision activities can express the same "do this only if X" logic. See Conditional activity or decision activity? A quick trade-off below for how to choose. And decision activities and decision stages are the same mechanism at two different scopes; see Part 2 » for that comparison.
Combining Patterns: The Full Picture
In practice, a mature KM automation strategy will combine multiple patterns. For example:
Your Article Creation playbook uses conditional activities for quiet optional steps and a decision activity for the one branch worth showing on the canvas, then embeds the Content Quality Review nested playbook before publishing. The base playbook hosts variants for different knowledge bases. And the Feedback Triage playbook feeds corrected articles through the quality review, while decision stages route each article to the right review path.
The guiding principle stays the same across every article in this series: start with the simplest mechanism that meets the requirement.
Use Case: Article Creation with Conditional Activities and a Decision Activity
The scenario. A knowledge worker creates a new article from a resolved incident. The core process is always the same: draft, review, publish. But some steps should only run under certain conditions. If the article is visible to external users, we need a compliance check. If the article includes attachments, we need an attachment review. If the knowledge base has translations enabled, we want to auto request translations after publishing.
Why use conditional activities, and where a decision activity fits instead. The overall playbook shape doesn't change; the stages are the same for every article. Attachment review and requesting translations are simple, independent toggles, so they stay as conditional activities (the 'Run condition' property), the simplest way to skip or include a step without complicating the design. The external publishing compliance check is different: whether the article is external is a central fact about the record and knowing at a glance whether that path was taken matters to anyone reviewing the diagram. So, this article models it as a decision activity instead, with an explicit "External" branch and a built-in "Else" branch, even though the runtime effect is the same as a run condition would have produced. See the section "Conditional activity or decision activity? A quick trade-off below" for why.
Note: The activities highlighted in green in the diagram are conditional; they're always part of the playbook definition but only execute when their run condition evaluates to true. The compliance check is instead a diamond with two labeled branches, so its logic is visible without opening any activity's properties.
Tip: To configure a run condition, select the activity, open the Details tab, select Show additional options, and set the 'Run condition' field. To configure a decision activity instead, see Part 2: Decision Activities and Decision Stages ».
Conditional activity or decision activity? A quick trade-off
Both forms of the compliance check produce the identical runtime result: external articles see the guidance; internal articles skip straight to attachment review. The difference is entirely about what's visible on the canvas:
|
|
Run condition (conditional activity) |
Decision activity |
|
Canvas footprint |
Zero extra nodes; the condition lives in the activity's properties |
One extra diamond node, with labeled branches |
|
Discoverability |
Only visible if you open the activity, or if the diagram uses a color convention like this article does |
Visible to anyone looking at the diagram, no clicks required |
|
Mechanism |
Condition builder, evaluated once, either runs or skips the activity |
Same condition builder, evaluated per branch, always includes a built-in "Else" |
|
Best fit |
Simple, independent toggles that don't need to be a talking point on the diagram |
A condition that's central to the process, maintained by more than one person, or likely to grow a real "else" path later |
Neither option is more "correct", they're the same underlying mechanism at different levels of visibility. Default to a run condition for a quiet, independent skip like attachment review or requesting translations. Reach for a decision activity when the branch is important enough that you want it to be self-evident to the next person who opens the playbook, even if, like here, one side of the branch is just "do nothing and continue."
One More Variation: Conditional Stages
Everything above talks about adding conditions to individual activities, but the same Run condition property also exists on stages, not just activities. Set it in a stage's Details tab the same way you would for an activity, and the entire stage is skipped at runtime if the condition evaluates to false, no activities inside it run, and the process worker never sees it. It's the same mechanism, the same condition builder, just scoped one level up. Reach for it when an entire stage, not just one step, is only relevant to some records, for example an internal only knowledge base that skips a formal review stage entirely.
Conclusion
In summary:
- Playbooks are ideal for KM processes because knowledge workers need guided, in context experiences, not background automation. Playbook Experience renders your stages and activities wherever the process workers do their job, keeping them focused on the tasks ahead.
- Match the dynamic feature to the scope of change. Conditional activities and stages handle simple skip or include logic. Decision activities and decision stages apply that same conditions-driven branching at two different scopes, within a stage, or between entire stages. Variants modify activities within shared stages. Nested playbooks encapsulate reusable process segments.
- Every activity across every pattern in this series is out of the box (OOB). You don't need to create custom activity definitions to get started. For an AI boost, enable the AI Agent toggle on User Form and Email activities where research or slot filling would save time.
- Reach for conditional activities for a quiet, independent skip or include that doesn't need to be visible on the diagram. Reach for a decision activity instead when that same condition is important enough that you want the branch, and its "else," self-evident on canvas, when the branches lead to genuinely different downstream activities, or when the agent needs to actively choose between paths.
Ready to go deeper? Continue to Part 2: Decision Activities and Decision Stages » or jump to whichever pattern matches your current requirement using the quick reference table above.
We want to hear from you. If you've built a dynamic playbook using one of these patterns, or you have a KM (or non-KM) use case that doesn't quite fit the examples here, drop it in the comments. We're always looking for real world patterns to feature in future CoE content.
Series Navigation
|
Part |
Article |
Link |
|
1 |
Overview and Conditional Activities |
(this article) |
|
2 |
Decision Activities and Decision Stages |
|
|
3 |
Playbook Variants |
|
|
4 |
Nested Playbooks |
