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

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# User access to Playbooks in Workflow Studio

# User access to Playbooks in Workflow Studio {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 User access to Playbooks in Workflow Studio

This guide explains how administrators can manage user access to Playbooks within Workflow Studio in ServiceNow.
Access is controlled through user roles, delegated development permissions, and content filtering, enabling fine-grained control over who can view, create, edit, or manage Playbook components.
Show full answer Show less  

## Key Features

* **Role-Based Access:** Administrators assign specific roles to users that dictate their permissions in Workflow Studio. Key roles include:
  * **playbook.admin:** Full control over playbooks, triggers, activity definitions, and shared experience activity types.
  * **pdauthor:** Ability to create, activate, edit, and delete playbooks and view activity definitions.
  * **pdcontentauthor:** Manage activity and trigger definitions and view shared activity types.
  * **pdtriggerauthor:** Manage trigger definitions exclusively.
  * **pdoperator:** View process executions and logs without editing rights.
  * **pdcancel:** Allow canceling running playbooks without full admin or write rights.
  * Additional specialized roles support restarting playbooks, reading activity definitions, and content filtering compliance.
* **Delegated Development Access:** Administrators can assign delegated development permissions by creating applications and adding users as developers. This controls access to admin-restricted features for playbook authors.
* **Role-Based Content Filtering:** Administrators can define content filtering rules and content definitions to restrict access to certain playbook content (e.g., activity and process definitions) based on user roles.
* **Activity Definition Access Control:** Activity definitions can have required roles specified. Users without these roles will see only a read-only view of related playbooks, ensuring sensitive activities are protected.
* **Supporting Roles:** Some roles such as *snworkflowstudio.workflowstudioread* and *sndiagrambuilder.dbread* allow users to launch Workflow Studio and view playbooks but are not managed by playbook administrators.

## Practical Outcomes for ServiceNow Customers

* Administrators gain precise control over who can create, edit, view, cancel, or restart playbooks, improving security and governance in workflow automation.
* Role-based access and content filtering ensure users only access appropriate Playbook features and content according to their responsibilities.
* Delegated development enables non-admin users to contribute to playbook development without exposing full administrative privileges.
* Activity definition role requirements enforce controlled access to sensitive workflow activities, preserving data integrity and compliance.
* By understanding and assigning the correct roles, administrators can streamline collaboration and maintain efficient workflow lifecycle management within Workflow Studio.  
Administrators can grant users access to Playbook by assigning delegated development permissions or directly assigning a user role. Administrators can also specify which features and content a user can access based on user roles.

## Access by user role {#user-access-playbooks__section_u5t_v5w_cbc}

Administrators can grant access to Playbook in Workflow Studio by directly assigning users the pd_author user role, which includes the role to view activity definitions.
{#user-access-playbooks__section_u5t_v5w_cbc__entry__3}

| Role | Description | Contains Roles |
|-|-|-|
| playbook.admin | Enables users to: * Create, update, and delete trigger definitions. * Launch Workflow Studio to create, activate, edit, and delete playbooks. * Create, edit, and delete activity definitions. * View the Experience activity types (sys_pd_activity) and Experience activity properties (sys_pd_activity_type_prop) tables that are shared by Playbooks and Playbook Experience. {#user-access-playbooks__ul_sxd_4lw_cbc} | * pd_author * pd_content_author * pd_trigger_author * pd_operator * pd_cancel {#user-access-playbooks__ul_jtv_nly_cbc} |
| pd_author | Enables users to: * Launch Workflow Studio to create, activate, edit, and delete playbooks. * View all activity definitions. * View the Experience activity types (sys_pd_activity) and Experience activity properties (sys_pd_activity_type_prop) tables that are shared by Playbooks and Playbook Experience. {#user-access-playbooks__ul_vpt_qmw_cbc} | * pd_shared.user * playbook.write * playbook.activity_def_read |
| pd_content_author | Enables users to: * Create, edit, and delete activity definitions. * Create, edit, and delete trigger definitions. * View the Experience activity types (sys_pd_activity) and Experience activity properties (sys_pd_activity_type_prop) tables that are shared by Playbooks and Playbook Experience. {#user-access-playbooks__ul_bgn_fqw_cbc} | * pd_trigger_author * pd_shared.user * playbook.activity_def_read |
| pd_trigger_author | Enables users to create, update, and delete trigger definitions. | none |
| pd_operator | Enables users to view process executions, activity executions, and execution logs only. | none |
| pd_shared.user | Enables users to view the Experience activity types (sys_pd_activity) and Experience activity properties (sys_pd_activity_type_prop) tables that are shared by Playbooks and Playbook Experience. | none |
| pd_shared.admin | Enables users to edit the Experience activity types (sys_pd_activity) and Experience activity properties (sys_pd_activity_type_prop) tables that are shared by Playbooks and Playbook Experience. | pd_shared.user |
| pd_cancel | Enables users to cancel running playbooks without the playbook.admin role or write access to the parent record. For example if you want to grant an agent manager the ability to cancel playbooks, but not an agent. | none |
| pd_restarter | Enables users to restart active playbooks. | none |
| playbook.write | Enables users who have content filtering restrictions to: * Launch Workflow Studio to create, activate, edit, and delete playbooks. * View the Experience activity types (sys_pd_activity) and Experience activity properties (sys_pd_activity_type_prop) tables that are shared by Playbooks and Playbook Experience. {#user-access-playbooks__ul_zv4_1nw_cbc}To learn more about content access filtering, see [Content filtering for Playbook](https://www.servicenow.com/docs/BR8KoukNyqH5uhtUSbb0jA "Specify which content a user can access based on the user's role."). | pd_shared.user |
| playbook.designer_access | Enables users who have content filtering restrictions to launch Workflow Studio to view playbooks. To learn more about content access filtering, see [Content filtering for Playbook](https://www.servicenow.com/docs/BR8KoukNyqH5uhtUSbb0jA "Specify which content a user can access based on the user's role."). | pd_shared.user |
| playbook.activity_def_read | Enables users to view all activity definitions as long as there aren't [Required Roles](https://www.servicenow.com/docs/BR8KoukNyqH5uhtUSbb0jA#content-filtering-playbooks__activity_def_req_roles). | none |
[Table 1. Roles for Playbook in Workflow Studio]

A visual representation of where roles are contained:

* playbook.admin
  * pd_content_author
    * playbook.activity_def_read
    * pd_shared.user
    * pd_trigger_author
    {#user-access-playbooks__ul_qw4_wqy_cbc}
  * pd_operator
  * pd_cancel
  * pd_restarter
  * pd_author
    * playbook.write
      * playbook.designer_access
        * pd_shared.user
        * sn_workflow_studio.workflow_studio_read  
          Note:  
          This role allows users to launch Workflow Studio, and is not managed by playbook administrators.
        * sn_diagram_builder.db_read  
          Note:  
          This role allows users to view playbooks in the diagram view in Workflow Studio, and is not managed by playbook administrators.
        {#user-access-playbooks__ul_wmk_kry_cbc}
      * 
      {#user-access-playbooks__ul_qmj_qzg_cgc}
    * playbook.activity_def_read
    {#user-access-playbooks__ul_gqv_jry_cbc}
  * pd_shared.admin
    * pd_shared.user
    * 
    {#user-access-playbooks__ul_hkt_c5n_gbc}
  {#user-access-playbooks__ul_gvw_2ry_cbc}
* delegated_developer
{#user-access-playbooks__ul_tcz_tqy_cbc}

## Delegated development access

Administrators can grant users access to Workflow Studio playbooks by creating an application and assigning users as developers with the playbook [delegated development](https://www.servicenow.com/docs/access?context=c_DelegatedDevelopment&version=brazil&pubname=brazil-application-development&ft:locale=en-US) permission. Delegated development allows administrators to control whether playbook authors can access features normally restricted to admin users. For more information, see [Developer permissions](https://www.servicenow.com/docs/access?context=developer-permissions&version=brazil&pubname=brazil-application-development&ft:locale=en-US).

## Role-based content filtering

Specify the user roles necessary to access Workflow Studio playbook content. For example, activity definitions and process definitions. Manage content filtering by creating content definitions and content filtering rules. For more information, see [Content filtering for Playbook](https://www.servicenow.com/docs/BR8KoukNyqH5uhtUSbb0jA "Specify which content a user can access based on the user's role.").

## Role-based activity definition access {#user-access-playbooks__section_zdp_4ww_cbc}

Manage activity definition access by specifying the Required Roles to access an activity definition. Users who can view the playbook but who do not have the required role to access activities with this
activity definition will have a read-only view of the playbook.

<br />

To learn more about activity definitions, see [Create an activity definition](https://www.servicenow.com/docs/3Hmw3j0I8zGJMb46wTfiug "Specify the action or subflow you want an activity to run. Configure the inputs you want playbook designers to set when adding the activity to a playbook. Select the experience you want end users to have when the activity runs.") and [Activity definitions](https://www.servicenow.com/docs/Ls~i4PA~qdO2CcO6dTkT3Q "Activity definitions describe how the activities in your playbook get the data that they need when your playbook runs.").  
Note:  
Both playbook.admin and pd_content_author roles can edit activity definitions, but only the playbook.admin role can edit the Required Roles field.
* **[Content filtering for Playbook](https://www.servicenow.com/docs/BR8KoukNyqH5uhtUSbb0jA)**   
  Specify which content a user can access based on the user's role.
* **[Configure content filtering definitions for Playbook](https://www.servicenow.com/docs/F06TbgR5~bAoSd7iYDDc6Q)**   
  Specify which content a user can access by creating content definitions.
* **[Configure content filtering rules for Playbook](https://www.servicenow.com/docs/jQ1xzKpWVke0vnFiqR98Dw)**   
  Use content filtering rules to specify the role a user must have to access content.

