Playbooks Best Practices - Workflow Automation CoE

[Lisa Holenstein]

Workflow Automation CoE > Playbooks > Best Practices

Guidance and practical tips

Application Scope

• Create Process Definitions and Activity Definitions in a scoped application
• Use ServiceNow source control integration with Git for versioning, forking, and branching of your processes and process activities
• Application names should not include a version as part of the name

Keep an eye on triggers to avoid parallel, conflicting logic

When creating new process definitions, keep track of existing business logic like flows and business rules triggering at the same conditions (e.g., categories, types, states,…) that run potentially conflicting logic.

Creating subflows or flow actions to power process activity definitions

Flow Designer is the tool of choice to automate self-contained units of logic, always keep reusability in mind. While you can use flows to power your activity definitions, we recommend using subflows and flow actions instead, because they allow you to specify inputs and outputs, which simultaneously serve as activity inputs and outputs.

• As such, I will recommend reducing scripting where possible. When you find yourself using similar inline scripts regularly, consider creating a Utils Spoke with several reusable actions
• Flow Actions should only ever do one thing at a time (e.g., calculate a value, get data from a remote system)
• Subflows are groupings of actions for reusability (e.g., approval, making a decision & some following actions with the decision result, etc.)

Keep reusability in mind

When creating declarative actions for activity definitions that may be used in other processes as well, don’t script visibility conditions based on activity/lane names. Base the conditions off of record fields instead (e.g., state, category,…). The same rule applies to lane or activity conditions as well.

This will be specifically important with the (new in Tokyo) copy process feature. Once you start copying and adjusting an existing process definition to another process’ needs (for example by renaming lanes), you may run into issues down the line if you don’t heed this recommendation.

Naming convention

• Include a description for your Playbook
• Use human-readable names for Playbook Name, Activity Definition Name, Flow Name, Subflow Inputs, and Subflow Outputs.
• All Input/Output labels use Camel Case with spaces.

Use optional activities for flexible process execution

Optional activities allow your processes to be more flexible and meet real agents’ daily requirements. Processes will not always follow the prescribed path and there will inevitably be unforeseen detours. With optional or adhoc activities you allow your agents to still follow the playbook on a high level, while accounting for situations that require a more flexible approach.

Center of Excellence Navigation

1. Workflow Automation - Center of Excellence
2. Workflow Automation Migration Considerations
3. What's new for Workflow Automation?
4. Resource Hubs
   1. Flows
   2. Decision Tables
   3. Playbooks
5. FAQ
6. Checklist
7. Training
8. Workflow Academy

[Raul16]

Thank you for this great best practice guide. I am missing a point related to customization of OOB Playbooks though: Shall OOB Playbooks rather be directly customized, as per general recommendation for the customization of ServiceNow features, or shall they rather be copied, and the copy modified, as it is recommended for e.g., Portal Widgets?

[Lisa Holenstein]

Hi @Raul16!

Thank you for reaching out. I'm glad the content is useful to you!

When it comes to the OOB playbooks, I'd say it depends on which playbook you're looking at and how much customization you expect to do.

If it's one that we ship with our Demo Store app, those are really just meant as examples and not production-ready playbooks. Those I would definitely copy if they look useful to you.

For playbooks that are shipped with one of our main products, like CSM, if you modify them instead of copying, you will receive updates to the playbook definitions when the product team releases updates and improvements via skipped records when you update the relevant store apps or instance release version.
If you are planning to make major changes to suit your needs, I'd consider creating a copy before modifying it, or creating your own playbook with the playbook activities included with the OOB store apps. If you're only planning minor changes and you want to receive updates to the playbooks when they are shipped, you might benefit from modifying the OOB playbook definitions.

I hope this helps!