--- sourceDocument: Australia Platform Analytics sourceDocumentLink: https://www.servicenow.com/docs/r/now-intelligence Release : - australia ft:locale : - en-US ft:publication_title : - Australia Platform Analytics ft:clusterId : - par bundleId : - par workflow : - Platform --- # Report permission issues # Report permission issues {#ariaid-title1} * Release version: Australia * * Updated March 12, 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 Report permission issues This guide addresses common reasons why ServiceNow reports may display less data than expected or no data at all, focusing on permission-related issues. It explains how report sharing, access controls, and business rules impact report visibility and data completeness. The guidance also covers changes in report publication behavior introduced in the Australia release to improve security. Show full answer Show less ## Report Sharing and Visibility * By default, newly created reports are private to the creator and admins, and must be explicitly shared to be accessible by others. * Reports can be shared with individual users, groups, or roles to grant access. * Unshared reports do not appear in users' report lists or selection options and may show a message indicating limited visibility when embedded in dashboards. * Report owners or administrators can share reports using the sharing icon to grant appropriate access. ## Data Row Discrepancies in List Reports * Users may see differing numbers of rows in list reports due to read access controls (ACLs) applied on the report's source tables. * Each row is individually checked against ACLs, and rows that the user is not authorized to view are removed. * A message indicating rows removed due to security constraints may appear when data is filtered out. ## Incomplete Data in Non-List (Graphical) Reports * Non-list reports may show different data sets for different users because Before Query business rules on source tables restrict data before report generation. * These business rules enforce permission-based filtering, so users with different roles or group memberships see data filtered accordingly. ## Changes to Report Publication in Australia Release * All public Core UI reports are unpublished by default to enhance security, controlled by the glide.report.publishedreports.enabled property set to false. * Users with the reportadmin role can review unpublished reports and enable public access or sharing with logged-in users via the Reports Public \[sysreportpublic\] table. * To share a report with all logged-in users without making it fully public, set its Sharing setting to Everyone but do not publish it. ## Practical Implications for ServiceNow Customers Understanding and managing report sharing and permissions ensures that users see the correct data without unauthorized access. Administrators should verify report sharing settings and ACLs when users report missing or incomplete data. Awareness of the Australia release changes is important to maintain report visibility and security compliance. There are several reasons why a report is showing less information than expected or possibly no data at all. These include insufficient permissions on the report and the report not being shared. ## Report not shared {#report-permission-issues__section_vth_lvn_1vb} A common reason that a report may not be viewable is that the report hasn't been shared with the users who are attempting to access it. By default, a newly created report won't be shared and therefore inaccessible to anyone except the report creator or users with the admin role. A report can be shared with an individual user, with one or more groups, or assigned to one or more roles. Unshared reports don't appear in lists of reports a user has access to or in other options in which a report might be opened or selected. When users are able to see a dashboard the report has been added to, but not the report itself, a message indicates that the "Report is visible only to a specific user or group". To correct this issue, the owner of the report (or an administrator) can share that report with the individuals who should have visibility and access to that report. You can share a report directly from the report's sharing icon. For more information, see [Share a Core UI report](https://www.servicenow.com/docs/dbGEOlwIH~2ssqzRKvI2mA "Control which users and groups can see a report in their Reports list."). ## List reports show fewer rows than expected {#report-permission-issues__section_hzw_ywn_1vb} Another common issue is that fewer rows appear in list reports than the viewer expects. For example, one user sees 100 rows in a list report, but another user, viewing that same report may see fewer rows or even no rows at all. When one or more rows have been removed from the report, a message indicates the number rows removed due to security constraints. The usual cause is that each row of a list report is first compared against any read access control lists (ACLs) defined on the report's source tables. The ACL is considered for each list row that might be displayed in a report. For more information, see [Report_view access control](https://www.servicenow.com/docs/QgE_GfTu~k~fVRRIcl5v2w "The report_view operation is a record type access control list (ACL) that restricts access to reports. Only users who have one of the required roles can view reports that contain the restricted resource."). ## Non-list reports show incomplete data {#report-permission-issues__section_scd_pyn_1vb} Graphical reports (defined as any non-list type report) may show an incomplete set of data for one user, as compared to another user reviewing that same report. This issue is caused by the fact that Before Query business rules are performed on the data from the source table before a report is generated and rendered. Business rules, found on a report's source tables, limit the data based on permissions or similar criteria. Any records that don't fulfill the rule's criteria aren't included in the report. Therefore, users with differing permission levels (due to group or role permissions mainly) see the same report showing different results. For more information, see [Before Query business rules](https://www.servicenow.com/docs/access?context=bp-before-query-business-rules&version=australia&pubname=australia-platform-security&ft:locale=en-US). ## Reports no longer public {#report-permission-issues__section_lxp_3sy_4hc} On upgrade to Australia, all public Core UI reports are unpublished to enhance security awareness and control. The glide.report.published_reports.enabled property on all Core UI reports is set to false. Users with the report_admin role can navigate to the Reports Public \[sys_report_public\] table to view unpublished reports and enable the public capacity or enable sharing with logged in users inside the platform. For more information, see [(Legacy) Publish a report](https://www.servicenow.com/docs/JwSA7A35f5e~eXIR6BhnSw#t_PublishAReport "Publish a report to create a URL that anyone can use to access the report, including people who are not users. When anyone navigates to the URL, the report is generated with current data from the instance. Reports are available until they are unpublished."). Note: To make a Core UI report available only to users who are logged in, set its Sharing setting to Everyone, but do not publish it.