--- sourceDocument: Australia Build workflows sourceDocumentLink: https://www.servicenow.com/docs/r/australia/build-workflows Release : - australia ft:locale : - en-US ft:publication_title : - Australia Build workflows ft:clusterId : - crworkflow bundleId : - crworkflow workflow : - Creator --- # Public access playbooks permissions # Public access playbooks permissions {#ariaid-title1} Release version: Australia Updated September 10, 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 Public access playbooks permissions Public access playbooks in ServiceNow enable users without ServiceNow logins to interact with playbooks. These playbooks employ unique authoring roles and specific restrictions distinct from standard playbooks to accommodate users who cannot be assigned standard roles. This functionality is critical for extending playbook capabilities to unauthenticated or guest users while maintaining security and controlled data access. Show full answer Show less ## Key Features * **Specialized Authoring Roles:** * `playbook.write.publicaccess` -- Required to create and edit public access playbooks; without it, users have read-only access. * `playbook.contentauthor.publicaccess` -- Required to edit the public access field on activity definitions. * `playbook.automationrunner` -- Used by automations running within public access playbooks, providing limited system privileges. * **Public Access Restrictions:** * Public access must be enabled at playbook creation; existing playbooks cannot be converted. * Playbooks must have a parent record; standalone playbooks cannot be public. * Only activities with public access enabled can be included; some have this enabled by default. * Only other public access playbooks may be nested inside a public access playbook. * Playbook type settings govern allowed or blocked public features. * Guest users require proper access controls to parent records; public access does not bypass record-level security. * Runtime APIs and messaging require guest-safe access control rules. * Automations must be wrapped in activity definitions for use in public access playbooks. * Data unauthorized for guest users is entirely hidden rather than partially restricted. ## Practical Considerations for ServiceNow Customers * **Security and Data Exposure:** Because public access playbooks are accessible to unauthenticated users, careful review of access control rules on APIs, messaging channels, and activity definitions is essential to prevent unintended data exposure. * **Automation Restrictions:** Automations run under a restricted runner with limited privileges, so assess what flow data automations can access to maintain security. * **Performance Planning:** Since any user who can access the embedded playbook page can start the playbook, anticipate and plan for potential high volumes of requests. * **Activity Definition Management:** Enable public access on activity definitions only after thorough review, as this makes them available to all public access playbooks. 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/yo5rKB7uQ2JLlRfi115IiQ "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.