--- sourceDocument: Australia Platform Analytics sourceDocumentLink: https://www.servicenow.com/docs/r/australia/now-intelligence Release : - australia ft:locale : - en-US ft:publication_title : - Australia Platform Analytics ft:clusterId : - par bundleId : - par workflow : - Platform --- # Report_view access control # Report_view access control {#ariaid-title1} Release version: Australia Updated March 12, 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 Reportview access control Thereportviewoperation is a record-type access control list (ACL) in ServiceNow that restricts access to data visualizations and Core UI reports. Only users with specific roles or meeting security attribute conditions can view visualizations containing restricted resources. This ACL type applies at the table or field level and controls visibility of data shown in reports and visualizations. Show full answer Show less ## Creating and Configuring reportview ACLs * Create a record ACL with type **record** and operation **reportview**. * Specify the target table in the first table field. * For field-level control, specify a particular field or use a wildcard () to apply the ACL to all fields on the table. Leaving the field empty creates a row-level ACL. * Define at least one role or security attribute condition (data and advanced conditions are not supported). * Use decision types such as **Allow If** to grant access based on roles or **Deny Unless** to enforce conditions. ## Table vs Field Level reportview Rules Table-level rules control access to visualizations of the entire table's data. Field-level rules restrict access to visualizations displaying specific fields, including any visualizations with data source conditions on those fields. Field-level ACLs also apply to reference (dot-walked) fields. Example: A field-level reportview ACL requiring the **chatadmin** role for viewing the Assignment Group field in Chat Queue visualizations restricts users without that role from seeing visuals filtered by that field. ## Design Considerations for reportview ACLs * Typically, restrict visualization access by requiring specific roles using an **Allow If** decision type. * Alternatively, enforce access based on security attribute conditions with a **Deny Unless** decision type. * Note that list visualizations and Core UI list reports do not use reportview ACLs; instead, they rely on **read** operation ACLs to control record data access. ## Practical Use Cases * **Field ACL with roles:** Granting the **paadmin** role access to all Performance Analytics cached forecast table fields by creating a reportview ACL with wildcard field and role assignment. * **Table ACL with security attribute:** Restricting Incident table visualizations to logged-in users by applying a reportview ACL using the **UserIsAuthenticated** security attribute and a Deny Unless decision type. ## Fallback Behavior If no reportview ACL exists for a data visualization, ServiceNow falls back to evaluating table-level **read** ACL roles to determine access. The report_view operation is a record type ACL that restricts access to data visualizations and Core UI reports. Only users who have one of the required roles can view visualizations that contain the restricted resource. To create a report_view ACL, follow the [general procedure for creating an ACL rule](https://www.servicenow.com/docs/access?context=t_CreateAnACLRule&version=australia&pubname=australia-platform-security&ft:locale=en-US). Create an ACL rule with the following settings: * Type: record * Operation: report_view * First table field: Required. Enter the name of the table on which to apply the ACL rule. * Second (unlabeled) table field: If you want the ACL rule to apply to a specific field on the table, select the field name here. Select a wildcard (\*) to give access to all fields on the table. Leave this field empty to create a row-level ACL rule, which gives access to the table records. * Conditions: Specify at least one role OR at least one security attribute condition. Data conditions and advanced conditions are not supported. Set the other options freely. ## Table vs field report_view rules {#report-view-access-control__section_table-vs-field} Record-type ACL rules can apply to either a table or a field (or all fields) on a table. For report_view operations, a table rule allows only users with the specified roles to see the contents of visualizations of that table. A field rule allows only users with the specified roles to see visualization contents that show the field. A field rule also restricts all content of a visualization that has that field in its data source conditions. Field report_view rules also apply to reference (dot-walked) fields.{#report-view-access-control__r-v-acl-sd} For example, a report_view field ACL requires that users have the chat_admin role to view the Assignment Group field in visualizations of the Chat Queue table. This table is readable to all internal users. Two single-score visualizations are created that show the count of records on Chat Queue. One visualization has no conditions, and the other has Assignment Group = Database. Both visualizations are shared with a user who doesn't have the chat_admin role. This user can see the metric in the visualization without conditions. However, when they open the visualization with the condition on the Assignment Group field, they see that their access is restricted by the report_view ACL. ## Report_view operation design considerations {#report-view-access-control__section_mbc_z53_ptb} Use these guidelines when creating your own report_view operation access controls. Restrict access to visualizations by a required role : The report_view operation usually has an Allow If decision type, granting view access to visualizations to users with specified roles. Require conditions to be met to view a visualization : Instead of requiring user roles, a report_view operation can require conditions to be met. These conditions are defined by security attributes. Often these are basic conditions that must be met, so the report_view rule has the Deny Unless decision type. Restrict access to list visualizations with a read operation : List data visualizations and Core UI list reports do not follow report_view ACLs. Instead, they use record access controls that determine who can access data in a table or field. To restrict access to record data in lists, create a read operation access control. For more information about record access controls, see [Access control list rules](https://www.servicenow.com/docs/access?context=access-control-rules&version=australia&pubname=australia-platform-security&ft:locale=en-US). ## Report_view field ACL rule with roles {#report-view-access-control__example_report-view-roles} You need to grant access to visualizations of all fields on the Performance Analytics cached forecast table to users with the pa_admin role. Therefore you create an ACL rule. The rule affects visualization access, so you create a rule where type=record and operation=report_view. You specify the Cached forecast \[cached_forecast\] table. For the field, you specify the wildcard (\*). Doing so means that the rule grants viewing rights to visualizations of all fields on cached_forecast to users with the specified roles. Finally, you specify the pa_admin role. Figure 1. Report_view ACL rule giving access to all table fields to the pa_admin role ## Report_view table ACL rule with security access condition {#report-view-access-control__example_report-view-sec-ass-con} You want only logged-in users with roles to be able to see visualizations of the Incident \[incident\] table. You can't set these conditions with role requirements, but fortunately there is an existing [compound security attribute](https://www.servicenow.com/docs/access?context=compound-security-attributes&version=australia&pubname=australia-platform-security&ft:locale=en-US) called UserIsAuthenticated for this situation. Therefore, you create a report_view table ACL on Incident that uses this security attribute condition. You also set the decision type to Deny Unless. Doing so prohibits any user not logged in with a role from viewing visualizations of the Incident table, regardless of any other report_view ACL rules they satisfy. Figure 2. Report_view ACL rule requiring viewers to be logged in * **[Fallback ACL evaluation](https://www.servicenow.com/docs/~FHuFoCOYg5zd6o9G2sq_A)** When a data visualization is run, report_view access control lists (ACLs) are evaluated on the table and table fields that the report is based on. If no report_view ACL exists, there is a fallback check on table-level read ACL roles. **Related topics** * [Configure an ACL](https://www.servicenow.com/docs/access?context=t_CreateAnACLRule&version=australia&pubname=australia-platform-security&ft:locale=en-US) * [Security Attributes](https://www.servicenow.com/docs/access?context=security-attributes-landing&version=australia&pubname=australia-platform-security&ft:locale=en-US)