Workflow Automation CoE > Playbooks > Building Dynamic Playbooks > Part 3: Playbook Variants
This is Part 3 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 playbook variants.
Goal
In this article, you will learn how to use playbook variants in Workflow Studio to build a Knowledge Management (KM) article authoring playbook where the stage structure is identical across categories, but the activities within those stages differ.
Technology
|
Product/Feature |
Description |
|
End-to-end process automation with a guided user experience layered on top of subflows or flow actions |
|
|
Condition-based variations that modify activities within a shared stage structure |
Instructions
Use Case: KB-Specific Authoring with Playbook Variants
The scenario. Your organization has three knowledge bases: IT, HR, and Legal. The article authoring process follows the same three stages for all of them (Draft, Review, Publish). But the specific activities within those stages differ by knowledge base. IT articles need a duplicate check. HR articles need a PII compliance checklist. Legal articles need a disclaimer and dual approval.
Why playbook variants. The stage structure is identical across all three knowledge bases; only the activities within those stages change. Variants let you override activity properties and add additional activities per stage, all from a single base playbook. At runtime, the system evaluates which variant's conditions match and runs that variant automatically; agents don't pick.
Important: Variants currently cannot add or remove stages. They only modify activities within the shared stage structure. If you need different stages per knowledge base, you can use decision stages (see Part 2 ») or duplicate the playbook instead.
How variants work at the activity level
|
Stage |
Base (All Variants) |
IT Variant Adds |
HR Variant Adds |
Legal Variant Adds |
|
Draft |
User Form: Edit article |
Look Up Records: Duplicate check |
Checklist Task: PII compliance |
Instruction: Legal disclaimer |
|
Review |
Checklist Task: Content standard |
Instruction: Troubleshooting steps guidance |
Request Approval: HR manager |
Request Multi-Level Approval: Legal + Compliance |
|
Publish |
Auto Update Record: Publish; Send Email: Notify author |
(no changes) |
(no changes) |
(no changes) |
Note: Every activity listed in the "adds" columns is OOB. Variants inherit the base activities (shown grayed out in Workflow Studio) and layer variant specific activities on top. If you change or add an activity in a variant, it appears in full color.
Tip: To create variants, open the playbook, select the variant icon to open the variant panel, and select Add a variant. Set the condition (e.g., 'Knowledge base' is IT Knowledge Base) and click Create variant. Variants are evaluated top down; the first match wins.
Deferred Variant Evaluation
Variant evaluation doesn't have to happen at the start. By default, Workflow Studio evaluates every variant's conditions against the trigger data before the base playbook's first activity runs. If the value your conditions depend on isn't available yet at that point, you can move the evaluation to later in the diagram instead: select + after the activity where the value becomes available, then choose the variants icon from the mini-picker to add an evaluation point there.
Three constraints apply:
- The playbook does not have any variant activity before the evaluation point.
- Any prior activity does not overwrite the value of the evaluation point.
- The variant condition does not refer to any activity after the point.
In the KB authoring example above, "Knowledge base" is already known at trigger time, so the default works fine, but for a case where the matching signal only becomes available mid-playbook (e.g., branching a recruitment playbook on interview feedback gathered in an earlier stage), deferring the evaluation point is what makes variants usable at all.
Conclusion
Reach for playbook variants when the stage structure stays the same across categories, but the activities within those stages need to differ, and you want the system to pick the right version automatically rather than asking the agent to choose. If your categories actually need different stages, see Part 2: Decision Activities and Decision Stages » instead.
We want to hear from you. If you've used playbook variants to solve a similar problem, or you have a use case that doesn't quite fit this example, drop it in the comments.
Series Navigation
|
Part |
Article |
Link |
|
1 |
Overview and Conditional Activities |
|
|
2 |
Decision Activities and Decision Stages |
|
|
3 |
Playbook Variants |
(this article) |
|
4 |
Nested Playbooks |
