Playbooks in SPM: Guided Execution at Enterprise Scale

Josh Sutton · 59m ago

DISCLAIMER: This article describes Playbooks for Projects and Demands in Strategic Portfolio Management (SPM). Availability depends on your Project Workspace, Portfolio Planning, and Strategic Planning plugin versions (see the minimum plugin versions in Common Questions?). The features described are examples, not a complete list.

What problem does this solve?

Enterprise SPM deployments often struggle with consistency. Teams define their own intake steps, approvals, and status reviews, so the same work is governed differently across groups, and new managers have to learn the standard from scratch.

Playbooks give you a guided framework for each lifecycle. The framework shows what to do, when to do it, and where to find the tools. It gives you one governed standard across teams and removes the need to maintain many separate configurations.

This guide aligns to the ServiceNow SPM Best Practices Process Guides

Guided Execution for Projects and Demands

Projects follow the lifecycle (not states): Initiate > Plan > Execute > Close, with stages, action items, and recurring governance for approvals, status reports, actuals reviews, and forecast updates. Two out-of-the-box playbooks ship as examples:

Free-form (the Project default)
Linear (stage-gate)

Demands follow the lifecycle (not states): Ideation > Assessment > Prioritization > Planning. Required inputs, approvals, and validations are tracked per stage, and guidance is embedded directly in the demand record in Next Experience. One free-form playbook ships as an example.

You can create your own playbooks for both projects and demands.

Why it matters

Guided execution with step-by-step direction at every stage
Faster onboarding, so new managers learn the standard quickly
Improved predictability through fewer missed steps and errors
One governance standard across teams

One Platform, Tailored to the Work

Enterprise-Wide Deployment (EWD) lets multiple areas of an organization adopt SPM with tailored configurations while keeping a single enterprise framework for data and governance. Four things must flex independently without splitting the platform:

Security: users see only the records and screens they should.
Tailored layouts: screens display correctly for the governing condition.
Tailored processes: the system serves the right process based on the work.
Configuration independence: groups make the changes they need without affecting other groups.

The four pillars stay constant. What changes between groups is how much of each layer they add:

Out-of-the-box: what the product ships with
Standard additional: agreed enterprise extensions, such as fields required on all demands and projects
Specific: partition-level needs, such as extra fields for one type of demand or project

Key insight: Governance keeps this coherent. Common demand states across the organization let you compare like with like at the enterprise level.

It's the Type of Work, Not the Business Unit

A playbook attaches to a process, so variation can happen across business units and, just as often, inside one. These are the only scenarios, and are not hard rules, simply guidance

Scenario	What it looks like	Approach
One playbook, many groups	Project intake, status reporting, and stage gates run the same way everywhere	One playbook - Build once, govern centrally
Same work, different rules	IT and HR both run demands, but assessment criteria, approvals, and required inputs differ	One playbook with decisions and/or variant per BU
Different work, same group	Inside IT, an infrastructure project and an app-dev project are genuinely different processes	Multiple playbooks - The work decides the split, not the BU

How to decide

Keep one playbook when the process is common with minor variances. Handle those with branches and conditional steps.
Create multiple playbooks when the process is genuinely different, or when so many variances exist that one flow stops being readable, testable, and maintainable.

Key insight: Governance is the deciding factor. Pick the split that keeps the process guided, compliant, and easy to own.

Key Features That Make Playbooks Work

The list below covers common features aligned to SPM processes. It is not exhaustive.

Admin capabilities

Disable Skip: Override the default buttons (Mark Complete, Skip, Update) on a specific activity. For a global change, edit the activity default buttons instead. If a playbook should never allow Skip for a type of activity, create a custom activity modeled on an out-of-the-box one.
Show UI Preview: See how the playbook activity appears to the user.
Activity definitions: Browse the out-of-the-box activities at Process Automation > Playbook Administration > Activity Definitions.
Include all automation assets: When adding an activity, select this checkbox to add a subflow, flow, or action directly to the playbook without creating an activity definition. Use it when the activity only requires automation, does not need to be reusable, and the playbook does not require a UI.
Duplicate: Duplicate a previous activity. Available as of the Brazil release and not backported to earlier releases.

Playbook activities

Fields required for the step: Each step asks only for the inputs it needs, so users never face a full form up front. The result is a better experience and better data quality.
Questionnaire: Capture what the process needs through questions instead of custom fields. Answers drive downstream decisions and keep the data model clean.
Automation: Steps can trigger actions, approvals, and record updates automatically, so the playbook executes work rather than just describing it.
Decisions: Branch the playbook based on the activity, answer, or step. Decision tables decouple conditional business logic from playbook configuration, so a business change does not require a playbook change.
Creation of record: Create associated records for a demand or project.
Display other record: Show records created by a previous activity, and related lists, within the playbook experience.
Update of record: Update a field based on a previous activity or the next step.
Go back (loop): Return to a previous stage or activity based on a condition.
Attachments: Display the 'Add attachment' link directly in the Playbook step
Redirect to Section: Redirect users to a demand or project section, such as Financials and Resources.
Specific assignment: Assign steps to groups or users, or assign dynamically from a record reference field such as demand manager, project manager, or portfolio manager.

Key insight: Playbooks mean less configuration to maintain and a better user experience. They combine human interaction with automation.

What About Configuration Already in Place?

Existing configuration does not need to move wholesale. Review each item and decide where it belongs.

Move to a playbook activity	Leave as global automation
Stage-gated decisions: approvals and gate reviews tied to a lifecycle stage	Data integrity and calculations: rollups, field calculations, and field defaults
Guided tasks: intake forms, business case completion, kickoff checklists, closure steps	Scheduled jobs: overdue or stale-status reminders, periodic snapshots
Stage-specific notifications that only matter at one point	Governance and security: ACLs, mandatory fields on state changes, audit logging
Process-path routing that depends on the chosen path	Integrations: sync to finance, Agile, or external tools
Record creation driven by path or decisions: demand tasks, project template application, approval requests, artifacts	Records created outside playbooks: imports and API-created records
Existing Flow, Subflow, Action or Business Rules that can convert to a playbook activity or be used to create custom activities. (the record-level trigger is replaced with the Playbook flow	General notifications not tied to a specific process point

Key Insight: If the answer changes depending on the stage or an activity output, move it to the playbook. If it must always be true, keep it as global/record automation. Anything the organization needs to happen regardless should stay global, not sit in a playbook step that must be repeated if using multiple playbooks, or might be skipped.

Common Questions?

What are the minimum plugin versions for Playbooks?

Playbook for Project is available from Project Workspace version 7.0.0. Playbook for Demand is available from Portfolio Planning version 8.13.0 and Strategic Planning version 4.13.0.

What are the best practices when multiple personas work with the same playbook?

E.g. for a demand there is primarily the demand manager, but also stakeholders needs to touch the record, architecture, security, etc. (Other records – Demand Tasks, Cost Plans, Resource Assignments, etc.)

Which playbooks would benefit an organization that is several versions behind, and what approach works best given how hard change is?

The default Playbooks have not changed, and the minimum plugin version is still applicable.

What are the most common mistakes, and how can an organization that is not yet mature anticipate them?

Building too much too soon: Teams model every path before running real demands. Start with a simple playbook as a guide before adding hard controls. If compliance requires hard controls, start with the minimum needed to guarantee compliance.

Treating it as paperwork: Records get completed to tick boxes rather than to reflect reality. Tie stage progression to real decisions, such as requiring an approval before the next stage, and review data quality in regular governance meetings.

Not getting started: The great thing about Playbooks is it can, and should be, leveraged to help organizations that are “less mature”.

When a business unit needs a variation, how do I avoid the playbook fragmenting into many copies?

Use the approach in It's the Type of Work, Not the Business Unit above.

Which playbooks should an organization start with to speed up usage?

Review the out-of-the-box playbooks for Demand and Project as a starting point, and adjust them to reach the "minimal valuable process" for your organization.

How can organizations use playbooks to support Enterprise-Wide Deployment when each organization has different workflows and field requirements?

Handle workflow differences using the approach in It's the Type of Work, Not the Business Unit above. For fields, take three steps:

Define an Enterprise Data Model to use across organizations. It supports enterprise-level reporting and visibility, and holds the fields required to use other SPM capabilities.
Use Demand type (coming soon) and Project type and/or dynamic schema for additional, specific fields. For more on Project types, see Project types in Project Workspace.
Define a form view for each variation.

What suggestion do you have for teams with no defined processes who see playbooks as the next step?

Start with a simple playbook as a guide before adding hard controls. Review the out-of-the-box playbooks for Demand and Project as a starting point, and adjust them to reach the "minimal valuable process" for your organization.

Which roles can build and edit playbooks?

Several roles control who can build and change playbooks:

Role	Capability
`playbook.admin`	Full control: creates, edits, and deletes playbooks, activities, and triggers
`pd_author`	Launches the design environment to create, activate, edit, and delete playbooks; views all activity definitions and shared Experience tables
`pd_content_author`	Creates, edits, and deletes activity and trigger definitions; views shared Experience tables
`pd_trigger_author`	Creates, updates, and deletes trigger definitions

Delegating playbook access requires strong governance. Make sure patterns and standards are followed, that changes do not affect other playbooks, and that the deployment strategy is respected. For the complete list of roles, see the Playbooks roles documentation.

Can a playbook be copied and modified for different processes?

Yes, in three ways. You can duplicate (copy) a playbook, create a deviation/branch, or create variations on top of a base playbook (Playbook variants). For guidance on when to use each, see It's the Type of Work, Not the Business Unit above.

Can a Visio workflow be imported into a playbook?

Playbooks can be generated from text or an image. See Generate a playbook from text or image.

Requires Otto (AI) for Creator, which is included with Otto for SPM

(More to come on this, we are currently working on guidance specific to SPM Playbook)

What is the best way to learn how to apply playbooks to our space?

See How do we get started? Templates? below, which covers the Workflow Automation CoE guidance, the available courses, and the additional resources.

How do we get started? Templates?

Start with the out-of-the-box playbooks. Review the Demand and Project examples, and adjust them to reach the "minimal valuable process" for your organization.
Set up the data model first. Define an Enterprise Data Model shared across organizations for enterprise reporting, plus the fields needed for other SPM capabilities. Define a form view for each variation, if necessary. For projects, use project types with dynamic schema for specific fields. Demand types are coming soon.
Document the process. Create a visual or step-by-step process document, then map common steps to activities and write a requirements document.
Build, then share. Build with Creator, create a working template for the community, and involve product management early for feedback.
Learn the platform. Start with the Getting Started with Playbooks - Workflow Automation CoE guidance. Two courses are available: Playbook Essentials, covering fundamentals and how to build playbooks, and Playbooks Advanced, covering embedding playbooks in UIs and configuring custom activity UIs.

Additional resources

Key Considerations

Playbooks attach to processes, so design them around the type of work, not the organizational chart.
Keep global automation for anything that must always run, and use playbooks for stage- and path-dependent behavior.
Govern playbook access carefully when delegating editing rights.