---
sourceDocument: Australia Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/build-workflows

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Managing playbook permissions

# Managing playbook permissions {#ariaid-title1}

Release version: Australia  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Managing playbook permissions

This guide explains the mechanisms ServiceNow uses to control who can build, edit, and interact with playbooks.
Playbook permissions involve multiple layered controls on top of the platform's standard access control rules.
These mechanisms govern both design-time (authoring and editing) and runtime (interacting with running playbooks) permissions to ensure secure and appropriate access.
Show full answer Show less  

## Key Features

* **Roles:** Broadly grant create, update, and delete access. The `pdauthor` role provides full playbook authoring rights, while `playbook.write` allows editing with no read access unless paired with `playbook.read` or content filtering.
* **Delegated Development:** Restricts playbook editing to a single application scope while allowing use of activity definitions from other scopes, supporting modular and controlled development.
* **Content Access Filtering:** Enables fine-grained control to restrict access to specific activity definitions, playbook types, or resource tags during design time, complementing roles by narrowing access.
* **Runtime Permissions:** Configured by playbook authors in Workflow Studio, these control who can view and interact with playbooks once they are running, including actions like restarting or canceling.
* **Public Access Playbooks:** A special setting that adds restrictions enabling playbooks to be run by users without login credentials, with additional constraints compared to standard playbooks.

## How Permissions Work Together

* Users need the `sncinternal` role to access internal resources and write access to the activity's Experience Status Record to complete activities.
* Roles accumulate permissions hierarchically; assigning higher-level roles includes subordinate permissions.
* Required roles on activity definitions override content access filtering rules, ensuring stricter control.
* Platform-level access control rules apply independently and can block access regardless of playbook-specific permissions.
* Runtime permissions are always restrictive---adding conditions narrows access and overrides broader playbook settings.
* Permissions cascade from playbook to stages; the most specific setting takes precedence.
* Read-only views can result from lack of access to activity definitions or process definitions, or from configuration issues unrelated to permissions.
* Completing an activity requires write access to its Experience Status Record, separate from read permissions.

## Practical Application for ServiceNow Customers

ServiceNow customers can use these mechanisms to precisely control who can build, edit, and run playbooks within their environment. By combining roles, delegated development, and content filtering, organizations can tailor authoring rights to specific teams or applications. Runtime permissions allow playbook authors to define who can interact with running playbooks and perform critical actions like canceling or restarting.

Public access playbooks extend playbook usability to unauthenticated users with appropriate restrictions. Administrators configure design-time permissions globally via the platform UI, while playbook authors set runtime permissions per playbook in Workflow Studio. Understanding and applying these layered controls helps maintain security, governance, and operational efficiency in playbook management.  
Understand which mechanisms control who can build playbooks and who can interact with them while they run.

Playbooks control access through four mechanisms, each layered on top of the platform access control rules that apply to every table. Each mechanism serves a different purpose, and many configurations use more than one.

Two requirements apply regardless of which mechanism you use: all users need the snc_internal role to access internal resources, and completing an activity requires write access to that activity's Experience Status Record.

## The four mechanisms {#playbook-permissions__mechanisms}

Roles
:   Grant broad access. The pd_author role grants full create, update, and delete access to all playbooks. Grants access to use every activity definition when editing a playbook except for those activity definitions that specify Roles
    Required. Use playbook.write for cases where pd_author is too broad a role. On its own it grants no read access to playbooks. Pair it with playbook.read or with a content access filtering rule to let users edit playbooks and use
    activity definitions. Roles are hierarchical, so a higher-level role includes all roles beneath it. For more information, see [Role-based access](https://www.servicenow.com/docs/ggpv51UzX5llf_jVNiiIww "Assign roles to control who can view, create, and edit playbooks.").

Delegated development
:   Scope playbook access to edit playbook content within a single application, including Playbooks and Activity Definitions. Users can still use activity definitions from other scopes within their playbook. For more information, see [Delegated development access](https://www.servicenow.com/docs/eiYaayBSVGn3ArPBIIRBOQ "Delegated development scopes playbook access to edit Playbook content within a single application, including Playbooks and Activity Definitions. Users can still use activity definitions from other scopes within their playbooks.").

Content access filtering
:   Restricts access to specific content at design time. Create a content definition that describes the content, then create a filtering rule that specifies which roles can access it. You can filter by activity definition, by playbook
    type, or by resource tag. Use it when a role grants more access than a user should have. For example, the pd_author role allows users to edit any playbook and use any activity definition. You can grant a user playbook.write, which
    only lets them edit playbooks and use activity definitions that have been granted to them through content access filtering. For more information, see [Content filtering for Playbook](https://www.servicenow.com/docs/sWYxlsggbvQwCiqV~qd3TA "Specify which content a user can access based on the user's role.").

Runtime permissions
:   Controls which users can view and interact with a playbook that is already running. Playbook authors configure these settings during the build process, at the playbook and stage level. For more information, see [Runtime permissions](https://www.servicenow.com/docs/DaRwg6fDP8ZsE_KJLNjKUw "Runtime permissions restrict who can read, restart, cancel, and add optional activities to a running playbook.").

Public access playbooks are a playbook setting, not a separate mechanism. Enabling public access adds restrictions and removes none. For more information, see [Public access playbooks permissions](https://www.servicenow.com/docs/yIEIbN_4XmT0n2x0unmegA "Public access playbooks use their own authoring roles and follow restrictions that don't apply to other playbooks.").

## Design time and runtime {#playbook-permissions__design-time-and-runtime}

Roles, delegated development, and content access filtering control who can build and edit playbooks. Runtime permissions control who can act on a playbook that is already running.

Users need both types of access. Design-time mechanisms determine what someone can build. Runtime permissions determine what someone can do with a running playbook. To view a running playbook, a user must have read access on its
parent record in addition to any custom permissions defined by the playbook author.

Administrators configure design-time mechanisms in the platform UI, and those apply across the instance. Playbook authors configure runtime permissions inside Workflow Studio while building, and those apply to one playbook.

## Choosing a mechanism {#playbook-permissions__choosing-a-mechanism}

{#playbook-permissions__table-choosing-mechanism__entry__2}

| Goal | Mechanism |
|-|-|
| Let someone author playbooks without restriction | The pd_author role |
| Let someone author playbooks in one application only | Delegated development |
| Give read-only access to all playbooks | The playbook.read role |
| Show someone a subset of activity definitions | Content access filtering with the playbook.write role |
| Restrict access to edit a subset of playbooks | Content access filtering with the playbook.write role |
| Restrict one activity definition to a named role | Required roles on the activity definition |
| Let an operator cancel any playbook | The pd_cancel role |
| Restrict who can restart a playbook or add optional activities | Runtime permissions on the playbook |
| Run a playbook for users who have no login | Public access playbooks |
| Let a specific user or group complete an activity | Assignment on the activity's Experience Status Record |
[Table 1. Mechanism by goal]

{#playbook-permissions__table-choosing-mechanism}

## How the mechanisms interact {#playbook-permissions__how-mechanisms-interact}

Using multiple mechanisms together is common. The following rules explain what happens when mechanisms overlap.

Roles accumulate
:   Assigning a role grants all permissions that role includes. Assigning playbook.admin grants every playbook role beneath it.

Required roles override content access filtering
:   A user without the required role can't use an activity definition even when a content filtering rule grants access to it.

Access control rules are a separate layer
:   Read access control rules on playbook tables can call into content access filtering logic. This means a user can be blocked by an access control rule even when a content filtering rule grants access. For more information, see [Access control rules](https://www.servicenow.com/docs/27D7T3FOS19WQgW49PCr8g "Access control rules operate at the platform level, independently of playbook permissions. A user can satisfy every playbook permission and still be blocked.").

Runtime permissions only narrow access
:   The parent record defaults are required and can't be removed. Anything an author adds is a further condition. A playbook with runtime permissions configured is more restrictive than one without, never less.

Default permissions combine with AND; added permissions combine with OR
:   Read access on a playbook where the author added two roles resolves to read access on the parent record AND membership of the first role OR the second.

Runtime overrides cascade downward
:   A stage overrides the playbook. The most specific configuration takes precedence.

Read-only has several causes, only some related to permissions

:   A user who can't access every activity definition in a playbook sees a read-only view of that playbook, not a partial view. The same applies to a user without write access to the process definition. However, when a user is viewing
    a running playbook, an activity's form appears as read-only if there is no declarative action that requires form fields. This is a configuration issue rather than a permissions issue. Before concluding that a user lacks access, check
    declarative actions on the activity, the user's access to the activity definitions, and their write access to the process definition.

Completing an activity is governed separately

:   Reading an activity and completing it are different operations with different sources. Read access comes from runtime permissions and the parent record. Completing or skipping depends on write access to the activity's
    Experience Status Record.

Public access adds restrictions to every mechanism

:   A role or filtering rule that grants access in an ordinary playbook may grant less in a public access playbook. Guest users still need access to the parent record, only activities with public access enabled can be used, and only
    public access playbooks can be nested. For more information, see [Public access playbooks permissions](https://www.servicenow.com/docs/yIEIbN_4XmT0n2x0unmegA "Public access playbooks use their own authoring roles and follow restrictions that don't apply to other playbooks.").

* **[Role-based access](https://www.servicenow.com/docs/ggpv51UzX5llf_jVNiiIww)**   
  Assign roles to control who can view, create, and edit playbooks.
* **[Delegated development access](https://www.servicenow.com/docs/eiYaayBSVGn3ArPBIIRBOQ)**   
  Delegated development scopes playbook access to edit Playbook content within a single application, including Playbooks and Activity Definitions. Users can still use activity definitions from other scopes within their playbooks.
* **[Content access filtering](https://www.servicenow.com/docs/PuV~UsH2GgjGP9_wCaFM0w)**   
  Restrict access to subsets of playbook content by pairing a content definition with a filtering rule.
* **[Access control rules](https://www.servicenow.com/docs/27D7T3FOS19WQgW49PCr8g)**   
  Access control rules operate at the platform level, independently of playbook permissions. A user can satisfy every playbook permission and still be blocked.
* **[Runtime permissions](https://www.servicenow.com/docs/DaRwg6fDP8ZsE_KJLNjKUw)**   
  Runtime permissions restrict who can read, restart, cancel, and add optional activities to a running playbook.
* **[Public access playbooks permissions](https://www.servicenow.com/docs/yIEIbN_4XmT0n2x0unmegA)**   
  Public access playbooks use their own authoring roles and follow restrictions that don't apply to other playbooks.