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


---

# Runtime permissions

# Runtime 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 Runtime permissions

Runtime permissions in ServiceNow allow you to restrict who can read, restart, cancel, or add optional activities to a running playbook beyond the default access inherited from the parent record.
By default, users with read access to the parent record can read the playbook, and those with write access can restart it.
Runtime permissions enable playbook authors to add further restrictions during playbook design to better control access at both the playbook and individual stage levels.
Show full answer Show less  
These permissions only narrow access; the default parent record permissions always apply and cannot be removed. Any additional runtime permissions make the playbook more restrictive than the default settings.

## Key Features

* **Permission Logic:** Default parent record permissions use AND logic (all conditions must be met). Added runtime permissions use OR logic (any condition suffices) to grant access.
* **Operations You Can Restrict:**
  * **Read:** Viewing the playbook or stage at runtime (configurable at playbook or stage level)
  * **Restart:** Restarting the playbook or stage (configurable at playbook or stage level)
  * **Cancel:** Canceling a running playbook (configurable at playbook level)
  * **Add Optional Activity:** Adding optional activities to a stage at runtime (configurable at stage level)
* **Grouping Settings:** Apply permissions across entire levels, such as all stages or all activities in a playbook, streamlining access control.
* **Permission Sources:** Permissions can be granted based on:
  * Named users
  * User roles
  * User groups
  * User criteria (dynamic sets of users)
  * Specific records (not limited to the parent record)
* **Overrides:** Permissions set at a lower level (stage) override those set at a higher level (playbook). This allows for tailored access control, such as requiring additional roles for sensitive stages.

## How to Use

* **Configure Runtime Permissions for a Playbook:** Add permission sets to restrict who can view or act on the entire playbook during runtime.
* **Apply Runtime Permissions for a Stage:** Assign permission sets to specific stages to enforce different access requirements than the overall playbook, enabling granular control.

## Benefits for ServiceNow Customers

By implementing runtime permissions, you can ensure sensitive playbook content and actions are accessible only to authorized users, complying with security and process requirements. This fine-grained control helps prevent unauthorized viewing or modification of running playbooks, improving governance and operational integrity in your ServiceNow environment.  
Runtime permissions restrict who can read, restart, cancel, and add optional activities to a running playbook.

By default, access to a running playbook follows the parent record. Users who can read the parent record can read the playbook, and users who can write to the parent record can restart it.

This default grants wider access than some processes require. For example, every agent who can read a case can also read every stage of every playbook running on that case.  
Runtime permissions let a playbook author add further restrictions during playbook design. Configure permissions at the playbook level, then override them at the stage level where different access is needed.  
Note:  
Runtime permissions only narrow access. The default parent record requirements always remain in effect and can't be removed. Any permissions you add are additional conditions, so a playbook with runtime permissions configured is always more restrictive than one without.

## How conditions combine {#runtime-permissions-playbooks__how-conditions-combine}

Default permissions are required and combine with AND logic, meaning all conditions must be satisfied. Permissions that you add to an operation combine with OR logic, meaning any one condition is sufficient.

If a playbook author adds two roles to the Read operation, users need read access on the parent record AND membership in the first role OR the second role.

## Operations you can restrict {#runtime-permissions-playbooks__operations}

{#runtime-permissions-playbooks__table-operations__entry__3}

| Operation | Configurable at | Governs |
|-|-|-|
| Read | Playbook, stage | Viewing the playbook or stage at runtime |
| Restart | Playbook, stage | Restarting the playbook or stage |
| Cancel | Playbook | Canceling a running playbook |
| Add optional activity | Stage | Adding an optional activity to a stage at runtime |
[Table 1. Runtime permission operations]

{#runtime-permissions-playbooks__table-operations}

## Grouping settings {#runtime-permissions-playbooks__grouping-settings}

Grouping settings apply a permission across an entire level rather than to each item individually.

* Restart for all stages in a playbook
* Add optional activity for all stages in a playbook
* Restart for all activities in a playbook or a stage
{#runtime-permissions-playbooks__ul_wjq_3j5_gkc}

## Permission sources {#runtime-permissions-playbooks__sources}

{#runtime-permissions-playbooks__table-sources__entry__2}

| Source | Grants the permission to |
|-|-|
| User | A named user |
| User role | Users holding the specified role |
| User group | Members of the specified group |
| User criteria | Users matching the specified user criteria record |
[Table 2. Sources you can grant a permission from]

{#runtime-permissions-playbooks__table-sources}

The two record access sources can point at any record, not only the parent record of the playbook.

## Overrides {#runtime-permissions-playbooks__overrides}

Permissions configured at a lower level override those at the level above. A stage overrides the playbook. Where no override exists, the permissions from the level above apply.

Use an override when one part of a playbook requires different access from the rest. For example, a stage that handles payment details can require a role that the playbook as a whole doesn't.
* **[Configure runtime permissions for a playbook](https://www.servicenow.com/docs/s_G26toNBKhh_XOuwG1xIw)**   
  Add permission sets to a playbook to restrict who can view and act on it at runtime.
* **[Apply runtime permissions for a stage](https://www.servicenow.com/docs/h2GymQWdcZhqXm2wtTqp8A)**   
  Add permission sets to one stage to give the stage different runtime access from the rest of the playbook.