Public access playbooks permissions

concept australia Updated Sep 10, 2026 2 min read public-access-playbooks-permissions.md
Raw file servicenow.com

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.

Roles for authoring public access playbooks

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

Risks and considerations

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.

Parent Topic:Managing playbook permissions

Search documentation
Search document titles and file paths on the australia branch