--- 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 --- # Access control rules # Access control rules {#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 Access control rules Access control rules in ServiceNow operate at the platform level and are independent of playbook permissions. Even if a user meets all playbook permissions, they can still be blocked by access control rules, which apply to playbook tables just like any other tables. These rules govern what users can see and do within playbooks, ensuring security beyond the playbook-specific role settings. Show full answer Show less ## Content Access Filtering Read access to playbook content is controlled by access control rules that may invoke content access filtering and resource filter rules. A user may be blocked by access control despite content filtering granting access. If a user cannot see content that content filtering allows, checking access control rules on the relevant playbook table should be the first troubleshooting step before modifying filtering rules. ## Completing and Skipping Activities The ability to complete or skip an activity depends on write access to the activity's Experience Status record, typically a record in the **sysflowdata** table. This access is separate from playbook roles and runtime permissions. Non-admin users have write access only when: * Both the Assignment Group and Assigned to fields are empty (open access). * The Assignment Group is empty and the user is specifically assigned in the Assigned to field. * The Assignment Group is set to a group of which the user is a member. To grant users the ability to complete activities, configure either the Assigned to field or the Assignment Group field accordingly. Access control rules on **sysflowdata** enforce these permissions. When users can see an activity but cannot complete it, reviewing these fields is a key troubleshooting step before checking playbook roles or runtime permissions. ## Public Access Playbooks Guest users (unauthenticated) access playbook runtime through access control rules applied to runtime APIs and messaging channels. These rules control what data guest users can retrieve. Additionally, guest users require access to the parent record associated with the playbook. Proper configuration of these rules is essential for enabling public access playbooks. Specific guidance on required rules and roles is provided in ServiceNow documentation for guest user access and public access playbooks permissions. Access control rules operate at the platform level, independently of playbook permissions. A user can satisfy every playbook permission and still be blocked. Playbook tables are subject to access control rules in the same way as any other table. Access control rules are the platform-level access mechanism and operate independently of playbook permissions. For general information, see [Access Control Lists (ACLs)](https://www.servicenow.com/docs/access?context=access-control-rules&version=australia&pubname=australia-platform-security&ft:locale=en-US). Because the two are independent, a user can satisfy every playbook permission and still be blocked by an access control rule. The following sections cover where this happens. ## Content access filtering {#access-control-rules-playbooks__content-access-filtering} Access control rules for read operations on playbook tables can call into content access filtering and resource filter rule logic. A user can be blocked by an access control rule even when a content filtering rule grants access to the same content. Note: When a user can't see content that a content filtering rule grants them, check the access control rules on the playbook table before revising the filtering rule. ## Completing and skipping activities {#access-control-rules-playbooks__completing-and-skipping-activities} Whether a user can complete or skip an activity depends on write access to that activity's Experience Status record, which is usually a Flow Data record. This dependency is separate from playbook roles, content access filtering, and runtime permissions. A non-admin user has write access to a Flow Data record in three cases. * The Assignment Group and Assigned to fields are both empty, so any user can write to the record. * The Assignment Group field is empty and the user is named in the Assigned to field. * The Assignment Group field names a group that the user belongs to. {#access-control-rules-playbooks__ul_l2h_dgc_hkc} To give a user access to complete an activity, set the Assigned to field on the Flow Data record to that user. Alternatively, set the Assignment Group field and add the user to that group. Access is enforced by access control rules on the sys_flow_data table. Note: When a user can see an activity but can't complete it, check the Assignment Group and Assigned to fields before reviewing playbook roles or runtime permissions. ## Public access playbooks {#access-control-rules-playbooks__public-access-playbooks} Guest users reach the playbook runtime through access control rules on the runtime APIs and messaging channels. Those rules determine what an unauthenticated user can retrieve. Guest users also need access to the parent record. For the rules required and how to configure them, 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."). For the roles and restrictions that apply, see [Public access playbooks permissions](https://www.servicenow.com/docs/yIEIbN_4XmT0n2x0unmegA "Public access playbooks use their own authoring roles and follow restrictions that don't apply to other playbooks.").