--- sourceDocument: Yokohama Build workflows sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/build-workflows Release : - yokohama ft:locale : - en-US ft:publication_title : - Yokohama 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: Yokohama Updated January 30, 2025 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 ServiceNow administrators control user access to playbooks in Workflow Studio through role assignments or delegated development permissions. Access management allows tailoring what features and content users can see and interact with, ensuring appropriate permissions are granted for creating, editing, viewing, or managing playbooks and related components. Show full answer Show less ## Key Features * **Role-Based Access:** Users gain access to playbooks by being assigned specific roles such as `pdauthor`, `playbook.admin`, or other defined roles, each granting varying levels of permissions related to creating, editing, viewing, or canceling playbooks and activity definitions. * **Delegated Development Access:** Administrators can assign delegated development permissions by creating applications and designating users as developers. This controls access to advanced features typically reserved for administrators, allowing more granular control over author capabilities. * **Role-Based Content Filtering:** Access to specific playbook content, like activity definitions, can be controlled based on user roles. Content definitions and filtering rules enable administrators to specify which users see particular content, enhancing security and relevance. * **Activity Definition Access Control:** Administrators can specify required roles to access or edit activity definitions. While both `playbook.admin` and `pdcontentauthor` roles can edit activity definitions, only `playbook.admin` can modify the required roles for accessing those definitions. ## Key Outcomes * Administrators can precisely manage who can create, modify, or view playbooks and their components, improving governance and security. * Delegated development permissions enable flexible authoring capabilities without granting full administrative rights. * Content filtering ensures users only access relevant playbook content, simplifying user experience and reducing unauthorized access risks. * Role assignments and content filtering combined allow organizations to enforce least privilege principles effectively in Workflow Studio. Administrators can grant users access to playbooks 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 playbooks 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 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} | pd_shared.user | | playbook.activity_def_read | Enables users to view all activity definitions. | none | [Table 1. Roles for playbooks 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 * 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} * 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=yokohama&pubname=yokohama-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=yokohama&pubname=yokohama-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. Manage content filtering by creating content definitions and content filtering rules. For more information, see [Content filtering for playbooks](https://servicenow-prod.fluidtopics.net/qzKsghtfUSLl_WEiGAIgIw "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. To learn more about activity definitions, see [Activity definitions](https://servicenow-prod.fluidtopics.net/r014Lhz_11xoMRZZRHOzcA "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 playbooks](https://servicenow-prod.fluidtopics.net/qzKsghtfUSLl_WEiGAIgIw)** Specify which content a user can access based on the user's role. * **[Configure content filtering definitions for playbooks](https://servicenow-prod.fluidtopics.net/6_quWF7WwVuCevBO8cAhlw)** Specify which content a user can access by creating content definitions. * **[Configure content filtering rules for playbooks](https://servicenow-prod.fluidtopics.net/5xTWnIR7~PCMj6fdMt~cAQ)** Use content filtering rules to specify the role a user must have to access content.