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


---

# Public access playbooks permissions

# Public access playbooks permissions {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read  
Public access playbooks use their own authoring roles and follow restrictions that don't apply to other playbooks.

A public access playbook runs for users who don't have a ServiceNow login. Because these users can't be granted standard roles, public access playbooks use their own authoring roles and follow a set of restrictions that don't apply to
other playbooks.

For steps to set up and embed a public access playbook, see [Configure guest user access to playbooks](https://www.servicenow.com/docs/0Gp4P~trPxQgKVDT5p74fg "Set up a playbook, public audience record, and UI experience so that guest users can run playbooks without a ServiceNow login through a public URL.").

## Roles for authoring public access playbooks {#public-access-playbooks-permissions__authoring-roles}

playbook.write.public_access
:   Required to create and edit public access playbooks. Users without this role have read-only access. Delegated developers also require this role.

playbook.content_author.public_access
:   Required to edit the public access field on an activity definition.

playbook.automation_runner
:   The restricted runner that automations use when executing in a public access playbook. Automations run with limited system access, not broad system privileges.

## Restrictions {#public-access-playbooks-permissions__restrictions}

Public access playbooks are subject to the following restrictions:

* You can enable public access only when you create the playbook. You can't convert an existing playbook to public access.
* A playbook must have a parent record because runtime permission checks depend on it. Standalone playbooks can't be made public.
* Only activities with public access enabled can be included. Some activity definitions have public access enabled by default.
* Only other public access playbooks can be nested inside a public access playbook.
* Playbook type settings control which public features are allowed or blocked.
* Guest users still need access to the parent record through access control rules. Public access doesn't bypass record-level security.
* Runtime APIs and messaging channels require guest-safe access control rules and permission checks.
* Automations can't be used directly. Wrap each automation in an activity definition before using it.
* Any data that a guest user isn't authorized to view is hidden entirely, rather than displayed in a restricted form.
{#public-access-playbooks-permissions__ul_olw_4gq_hkc}

## Risks and considerations {#public-access-playbooks-permissions__risks}

A public access playbook is accessible to users you haven't authenticated. Review the following considerations before enabling public access:

Data exposure through APIs and messaging
:   Guest users access the playbook through runtime APIs and messaging channels. The access control rules on those endpoints determine what data a guest user can retrieve.

Flow data access
:   Automations in a public access playbook run under a restricted runner rather than with broad system access. Review what flow data the automations in your playbook can reach.

Load from public users
:   Anyone who can reach the page where the playbook is embedded can start it. Plan for the volume of requests this may generate.

Activity definition review
:   Enabling public access on an activity definition makes it available to all public access playbooks. Review each definition carefully before allowing public use.