--- 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 --- # Content access filtering # Content access filtering {#ariaid-title1} Release version: Australia Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 Content Access Filtering Content access filtering in ServiceNow enables you to restrict what subsets of playbook content users can see and edit at design time. This is particularly useful when a user's role grants broader access than intended, allowing you to fine-tune access beyond general roles likepdauthor. Instead, assign theplaybook.writerole combined with content access filtering to limit users to specific playbooks and activity definitions. Show full answer Show less ## Key Features * **Content Definitions:** Define the subset of content (such as playbooks or activity definitions) to be filtered. These can cover entire resources or be narrowed using conditions and resource tags. * **Content Filtering Rules:** Link roles to content definitions, specifying which roles can access which filtered content. * **Filtering Axes:** Filter by activity definition (which activities can be added), playbook type (which playbooks are visible), and resource tags (to refine filtering). * **Default Setup:** A default content definition covers all activity definitions, with filtering rules granting access to specific roles like **delegateddeveloper** and **playbook.activitydefread**. * **Read-Only Playbooks:** Users without access to all activity definitions in a playbook see that playbook as read-only, which can also result from lacking write permissions or form limitations. ## Practical Application for ServiceNow Customers * Use content access filtering to restrict users to only those playbooks and activities relevant to their role or business unit. * Create **content definitions** tailored to playbook types or activity definitions using conditions and tags. * Assign roles through **content filtering rules** to control design-time access precisely. * Choose **playbook.write** instead of **pdauthor** for users requiring filtered access, since **pdauthor** overrides filtering. * Manage exceptions by setting required roles directly on activity definitions to enforce stricter access. * Understand that content access filtering works alongside other permission controls like access control rules, which can further restrict content. ## Next Steps * Configure content filtering definitions to specify the content subsets to be controlled. * Create content filtering rules to assign access rights to roles. * Apply filtering by playbook type to limit user groups to relevant playbook categories. * Restrict activity definitions to specific users or roles as needed. Restrict access to subsets of playbook content by pairing a content definition with a filtering rule. Content access filtering restricts what a user sees at design time. Use it when a role grants broader access than specific users should have. For example, the pd_author role allows users to edit any playbook and use any activity definition. You can grant a user playbook.write, which only lets them edit playbooks and use activity definitions that have been granted to them through content access filtering. Filtering takes two records. A content definition describes a set of content. A content filtering rule names the roles that reach the content in that definition. Users need both the role named in the rule and a role that grants design-time access. Filter on three axes. Filter by activity definition to control which activities a user can add to a playbook. Filter by playbook type to control which playbooks a user can see. Filter by resource tag to refine either. Note: Assign the playbook.write role rather than pd_author to users who should see filtered content. The pd_author role grants access to all playbooks and all activity definitions, which overrides the restriction. ## Default content definition {#content-access-filtering-playbooks__default-content-definition} One content definition ships by default: Playbooks - All Activity Definitions. It covers every activity definition, and two default filtering rules point at it. One grants access to users with the delegated_developer role. The other grants access to users with the playbook.activity_def_read role. ## Content definitions {#content-access-filtering-playbooks__content-definitions} A content definition specifies a type of resource. Create a definition that covers an entire resource, or use the condition builder to narrow it. A definition on the activity definition table with a condition matching Guided Decision in the name or package covers only those activity definitions. A definition on the playbook table with a condition on playbook type covers only playbooks of that type. Refine a definition further with resource tags. For more information, see [Configure content filtering definitions](https://www.servicenow.com/docs/BFB4ZiODDPEO00E7q6FAkw "Create a content definition that describes a set of content a filtering rule grants access to."). ## Content filtering rules {#content-access-filtering-playbooks__content-filtering-rules} A content filtering rule specifies the role a user must have to reach the content in a content definition. Each rule associates one or more roles with a single content definition. To create one, see [Configure content filtering rules](https://www.servicenow.com/docs/EoO3nRgmaGqAxx537hcdMg "Create a rule that grants a role access to the content in a content definition."). ## Filtering by playbook type {#content-access-filtering-playbooks__filtering-by-playbook-type} Filtering on playbook type gives a group of users access to one category of playbook and no others. A business unit that owns its own playbook types can be restricted to those types. Create a content definition on the playbook table conditioned on playbook type, then a filtering rule that names a role for the group. For the procedure, see [Restrict access by playbook type](https://www.servicenow.com/docs/1i9MWbSNRZsMQCkHcNS~pw "Use content access filtering to give a group of users access only to playbooks of a specific type."). ## Filtering by activity definition {#content-access-filtering-playbooks__filtering-by-activity-definition} Filtering on activity definition controls which activities a user can add when building a playbook. To restrict a single activity definition to named roles instead, set required roles on the definition. Required roles override content access filtering, so a user without the required role can't use the activity definition even when a filtering rule grants access to it. For the procedure, see [Restrict access to an activity definition](https://www.servicenow.com/docs/e~ROLAWOz_xmKKZSP_5z4Q "Limit which users can add a specific activity definition to a playbook."). ## Read-only playbooks {#content-access-filtering-playbooks__read-only-playbooks} A user who can't reach every activity definition in a playbook gets a read-only view of that playbook. The same applies to a user without write access to the process definition. Read-only isn't necessarily a permissions problem. A form also displays as read-only when the activity has no declarative action that requires form fields. An editable form with no way to submit it is not useful. If a playbook appears read-only, confirm whether the user lacks content access before changing filtering rules. {#content-access-filtering-playbooks__table-access-summary__entry__3} | Content | With access | Without access | |-|-|-| | Activity definition | Visible and selectable when building a playbook. Can be copied and modified. | Hidden and not selectable. Playbooks that contain it are read-only. | [Table 1. Access to activity definitions] {#content-access-filtering-playbooks__table-access-summary} ## Related permissions {#content-access-filtering-playbooks__related} Content access filtering is one of four ways to control playbook access. For the others and how they interact, see [Managing playbook permissions](https://www.servicenow.com/docs/ste0zM0auM~u03mFsNXQcQ "Understand which mechanisms control who can build playbooks and who can interact with them while they run."). Access control rules operate as a separate layer and can block content that a filtering rule grants. For more information, see [Access control rules](https://www.servicenow.com/docs/27D7T3FOS19WQgW49PCr8g "Access control rules operate at the platform level, independently of playbook permissions. A user can satisfy every playbook permission and still be blocked."). * **[Configure content filtering definitions](https://www.servicenow.com/docs/BFB4ZiODDPEO00E7q6FAkw)** Create a content definition that describes a set of content a filtering rule grants access to. * **[Configure content filtering rules](https://www.servicenow.com/docs/EoO3nRgmaGqAxx537hcdMg)** Create a rule that grants a role access to the content in a content definition. * **[Restrict access by playbook type](https://www.servicenow.com/docs/1i9MWbSNRZsMQCkHcNS~pw)** Use content access filtering to give a group of users access only to playbooks of a specific type. * **[Restrict access to an activity definition](https://www.servicenow.com/docs/e~ROLAWOz_xmKKZSP_5z4Q)** Limit which users can add a specific activity definition to a playbook.