---
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


---

# Role-based access

# Role-based access {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read  
Assign roles to control who can view, create, and edit playbooks.  
Playbook roles are hierarchical. A higher role contains the roles beneath it, so assigning playbook.admin grants every role below it in the hierarchy. For the full list of roles and what each one permits, see [Playbooks roles](https://www.servicenow.com/docs/oTnzHgz~9hgTJ6X0U~66rQ "Grant users access to build, view, and act on Playbook.").  
Note:  
All users need the snc_internal role to access internal resources, including playbooks. A user without it can encounter trigger validation errors when a playbook attempts to run. This is a platform requirement rather than a playbook role.

## Choosing a role {#playbook-roles__choosing-a-role}

pd_author
:   Assign to users who author playbooks without restriction. Contains the write, designer access, and activity definition read roles. Grants access to use every activity definition when editing a playbook except for those activity
    definitions that specify Roles Required.

playbook.write
:   Assign instead of pd_author when content access filtering restricts what the user sees. Use it 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. For more information, see .

playbook.read
:   Assign to grant read-only access to all playbooks.

playbook.designer_access
:   Assign to let a user open Workflow Studio and view playbooks without granting edit rights.

pd_operator, pd_cancel, and pd_restarter
:   Assign to grant a single runtime capability without design-time access. The pd_cancel role lets a user cancel a running playbook without holding playbook.admin or write access to the parent record. For example, use this to grant a
    manager an ability that agents don't have.

## Roles outside playbook administration {#playbook-roles__roles-outside-playbook-administration}

The playbook.designer_access role contains two roles that playbook administrators don't manage. The sn_workflow_studio.workflow_studio_read role lets users to launch Workflow Studio. The sn_diagram_builder.db_read role allows users to view playbooks in diagram view.  
Note:  
Granting Playbooks roles doesn't grant access to the Workflow Studio design environment. Users who create activity definitions might also need Workflow Studio access. For more information, see [User access to Workflow Studio flows](https://www.servicenow.com/docs/PfaRoWpkBBI~dLgZfVF6jw "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.").

## Other ways to grant access {#playbook-roles__granting-access-other-ways}

Roles are one of several mechanisms. To scope access to a single application, see [Delegated development access](https://www.servicenow.com/docs/kvKPJFD9EtB4tyPgFF~z2g "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."). To restrict access to subsets of content, see [Content access filtering](https://www.servicenow.com/docs/1TZyxLL_QV2wIX_moHK70A "Restrict access to subsets of playbook content by pairing a content definition with a filtering rule."). For an overview of every mechanism, see [Managing playbook permissions](https://www.servicenow.com/docs/zWzwbDD5PonuY1R~vmVzUw "Understand which mechanisms control who can build playbooks and who can interact with them while they run.").