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


---

# Access control rules

# Access control rules {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read  
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=brazil&pubname=brazil-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/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."). For the roles and restrictions that apply, see [Public access playbooks permissions](https://www.servicenow.com/docs/mHtg58c4dmzFjIBvmu3amA "Public access playbooks use their own authoring roles and follow restrictions that don't apply to other playbooks.").