---
sourceDocument: Australia Build workflows
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/build-workflows

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# Playbooks roles

# Playbooks roles {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](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 Playbooks roles

This document outlines the roles available in ServiceNow Playbooks, enabling customers to grant specific permissions to users for creating, managing, and interacting with playbooks, triggers, and activity definitions.
Assigning the appropriate roles ensures users have the necessary access to build and operate playbooks effectively while maintaining security and content filtering controls.
Show full answer Show less  

## Available Roles and Their Functions

* **playbook.admin:** Full control to create, update, delete triggers, playbooks, and activity definitions; access Workflow Studio; manage translations; and view shared Experience activity tables.
* **pdauthor:** Can create, activate, edit, and delete playbooks in Workflow Studio and view all activity definitions and shared Experience activity tables.
* **pdcontentauthor:** Authorized to create, edit, delete activity definitions and triggers; view shared Experience activity tables.
* **pdtriggerauthor:** Permission to create, update, and delete trigger definitions.
* **pdoperator:** Read-only access to process executions, activity executions, and execution logs.
* **pdshared.user:** View access to shared Experience activity types and properties tables.
* **pdshared.admin:** Edit access to shared Experience activity types and properties tables.
* **pdcancel:** Allows users to cancel running playbooks without requiring playbook.admin role or write access to the parent record, useful for roles like agent managers.
* **pdrestarter:** Enables users to restart active playbooks.
* **playbook.write:** For users with content filtering restrictions, allows full playbook creation and editing capabilities in Workflow Studio and viewing of shared Experience activity tables.
* **playbook.designeraccess:** Allows users with content filtering restrictions to view playbooks in Workflow Studio.
* **playbook.activitydefread:** Grants read access to all activity definitions unless restricted by required roles.

## Additional Considerations

* Assigning Playbooks roles does **not** automatically grant access to Workflow Studio; separate permissions are required for the design environment.
* Playbook authors can apply additional runtime user access filters when building playbooks in Workflow Studio.
* For managing per-user subscriptions related to Playbooks, consult Subscription Management and your account representative.
* Content filtering roles (e.g., playbook.write, playbook.designeraccess) help enforce access restrictions based on organizational policies.  
Grant users one or more Playbooks roles to enable them to create triggers, playbooks, and activity definitions.

## Roles {#process-automation-designer-roles__section_zs5_mfw_blb}

To learn more about managing per-user subscriptions, see [Managing per-user subscriptions in Subscription Management](https://www.servicenow.com/docs/access?context=managing-user-subscriptions-v2&version=australia&pubname=australia-platform-administration&ft:locale=en-US) and contact your account representative.

System administrators can grant users access to Playbooks by assigning [delegated development permissions](https://www.servicenow.com/docs/access?context=c_DelegatedDevelopment&version=australia&pubname=australia-application-development&ft:locale=en-US) or directly assigning [Roles](https://www.servicenow.com/docs/access?context=exploring-user-administration&version=australia&pubname=australia-platform-administration&ft:locale=en-US). Additionally, playbook authors can create additional filters for runtime user access as they build a playbook in Workflow Studio. The following user roles are available for Playbooks:  
{#process-automation-designer-roles__table_h1y_drx_blb__entry__2}

| Role | Description |
|-|-|
| 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. * Add translations for a playbook. {#process-automation-designer-roles__ul_sxd_4lw_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. {#process-automation-designer-roles__ul_vpt_qmw_cbc} |
| 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. {#process-automation-designer-roles__ul_bgn_fqw_cbc} |
| pd_trigger_author | Enables users to create, update, and delete trigger definitions. |
| pd_operator | Enables users to view process executions, activity executions, and execution logs only. |
| 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. |
| 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_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. |
| pd_restarter | Enables users to restart active playbooks. |
| 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. {#process-automation-designer-roles__ul_zv4_1nw_cbc}To learn more about content access filtering, see [Content filtering for Playbook](https://servicenow-prod.fluidtopics.net/sWYxlsggbvQwCiqV~qd3TA "Specify which content a user can access based on the user's role.") |
| 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://servicenow-prod.fluidtopics.net/sWYxlsggbvQwCiqV~qd3TA "Specify which content a user can access based on the user's role."). |
| playbook.activity_def_read | Enables users to view all activity definitions as long as there aren't [Required Roles](https://servicenow-prod.fluidtopics.net/sWYxlsggbvQwCiqV~qd3TA#content-filtering-playbooks__activity_def_req_roles). |
[ ]

{#process-automation-designer-roles__table_h1y_drx_blb}  
Note:  
Granting users Playbooks roles does not automatically allow them to access the Workflow Studio design environment. Granting users access to Workflow Studio may be helpful when creating activity definitions. For more information on Workflow Studio roles, see [user access to Flow
Designer](https://servicenow-prod.fluidtopics.net/It9~lSDhYhBThAAusolhpg "Administrators can grant users access to Workflow Studio flows 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. Application developers can access Workflow Studio functionality through APIs for flows, subflows, and actions.").