Workflow Automation CoE > Playbooks > Building Dynamic Playbooks > Part 2: Decision Activities and Decision Stages
This is Part 2 of a four-part series on dynamic playbooks. Start with Part 1: Overview and Conditional Activities » for the full pattern lineup or continue below for the deep dive on decision activities and decision stages.
Goal
In this article, you will learn how to use decision activities and decision stages for playbooks in Workflow Studio. They're the same underlying pattern, conditions-driven branching, applied at two different scopes: decision activities route between activities within a stage, while decision stages route between entirely different stages. We'll build a Knowledge Management (KM) feedback triage playbook with the first, and an article review routing playbook with the second, so the distinction is concrete rather than theoretical.
Technology
|
Product/Feature |
Description |
|
End-to-end process automation with a guided user experience layered on top of subflows or flow actions |
|
|
Branching paths between activities within a stage or between stages, driven by conditions, showing only the relevant path at runtime |
Instructions
Decision Activities vs. Decision Stages: What's the Difference?
Decision activities and decision stages are one pattern, a conditions-driven fork, used at two different scopes, so it's worth being explicit about which scope applies before we get into the two scenarios below. Both look similar on a diagram, a diamond shaped fork with multiple branches: a decision activity's branches evaluate through the same condition builder as a decision stage's, and either one can route automatically off record data with no one choosing anything.
Tip: Use a questionnaire activity to leave the decision up to the process worker instead of using existing record data to evaluate the branch conditions.
|
|
Decision activities |
Decision stages |
|
Branches to |
Different activities within the same stage |
Entirely different stages |
|
Who decides |
Conditions on the record by default (same as a decision stage); pair with a Questionnaire if you want the agent to pick instead |
Conditions on the record by default; can also be paired with an agent choice earlier in the flow |
|
Best fit |
The work differs, but it's still one logical step in the process |
The work is different enough that it deserves its own stage(s) |
If you're not sure which scope you need, ask whether the branches represent different activities or different stages in your process. That answer tells you which scope to reach for.
Note: a decision activity's Details tab also has its own Run condition, separate from its branch conditions. That property gates whether the whole decision node runs at all; the branches then determine which path is taken once it does. This is the same Run condition property found on every other activity type, including the plain conditional activities from Part 1 ».
Use Case: Feedback Triage with Decision Activities
The scenario. When someone flags a knowledge article as inaccurate or outdated, a feedback record lands in the knowledge manager's queue. The manager needs to triage it: is this a quick fix they can handle right now, does it need a subject matter expert, or should the flag be dismissed? Each path involves completely different work, but it all happens within a single "Triage" stage.
Why a decision activity. We need the agent to make an explicit choice that routes to different activity paths within the same stage. A decision activity gives us a diamond shaped fork in the diagram where the agent picks a branch, and only that branch's activities appear at runtime.
Tip: Decision activities can only be added in Diagram view. Select the + icon, then choose the diamond icon from the mini picker.
Advanced tip: Add an AI agent to the questionnaire activity to analyze the feedback and KB article and then recommend a risk estimation for this change. This can either run in a collaborative way, so that the manager is still in charge and confirms the risk level, or even autonomously, if the AI agent has proven to generally make the correct decision.
Use Case: Article Review Routing with Decision Stages
The scenario. When an article moves into the Review state, the review process it needs depends on its risk level. Internal only articles for a low-risk knowledge base can go through a fast-track review (just a quality checklist and auto publish). External facing articles need a standard review with an approval gate. Articles in regulated knowledge bases (like compliance or legal) need a full compliance review with multi-level approval. These aren't just different activities within one stage; they're entirely different stages.
Why a decision stage. When the variation requires different stages (not just different activities within shared stages), a decision stage is the right tool. The decision node evaluates conditions and routes to one of three possible downstream stages. Only the relevant stage appears to the agent at runtime, which keeps the experience clean.
Note: Decision stages can only be added in Diagram view. The key difference from decision activities: decision stages route to entirely different stages, and only the selected stage appears to the end user at runtime. This keeps the agent focused on the relevant path.
A Decision Activity Can Also Replace a Single Conditional Activity
Both use cases above involve genuinely different downstream activities per branch. But a decision activity isn't limited to multi way forks like these; it also works for a plain, single condition toggle, the same job Part 1's conditional activities » handle. Add a decision activity with one condition branch plus its built-in "Else," and you get the identical runtime result as a Run condition on a single activity, just visible on the canvas as a labeled diamond instead of a property you'd otherwise have to open the activity to see. Part 1 walks through that exact comparison using its knowledge base compliance check. Neither approach is wrong: a run condition keeps the canvas lean for a quiet, independent toggle, while a decision activity makes the branch and its "else" self-evident to anyone reading the diagram, at the cost of one extra node.
Conclusion
Decision activities and decision stages are the same condition-driven branching pattern; only the scope changes. Reach for decision activities when branches lead to genuinely different activities within a single stage, or when a single condition is important enough that you want it visible on the canvas rather than tucked into an activity's properties. Reach for decision stages when the variation requires entirely different stages, not just different activities within a shared stage. If a condition is a quiet, independent toggle that doesn't need to be a talking point on the diagram, a plain conditional activity (see Part 1 ») remains the simplest option. If the difference across categories is only in which activities run within otherwise identical stages, see Part 3: Playbook Variants ».
We want to hear from you. If you've used decision activities or decision stages to solve a similar problem, or you have a use case that doesn't quite fit these examples, drop it in the comments.
Series Navigation
|
Part |
Article |
Link |
|
1 |
Overview and Conditional Activities |
|
|
2 |
Decision Activities and Decision Stages |
(this article) |
|
3 |
Playbook Variants |
|
|
4 |
Nested Playbooks |
