Content Base table list view not showing all records on one page

anil kharat1
Tera Contributor

Monday

There is an out-of-box table sn_cd_content_base.

When a user opens the list view for this table, only a few records are visible. The following message appears on the list view:

'Number of rows removed from this list by Security constraints: 40'

 

This indicates that records are being filtered due to security restrictions.

To troubleshoot this, I created a Query Business Rule and used GlideRecordSecure to apply a custom query. After applying this, the records appear correctly in the list view.

However, when the user clicks on any record from the list, instead of opening the existing record, the system redirects the user to a new record form.

 

Has anyone faced this issue or can explain why records open as new instead of the existing record?

Preview file
60 KB
Preview file
184 KB
Preview file
126 KB
0 Helpfuls
  • 252 Views
4 REPLIES 4

Sandeep Rajput
Tera Patron

Monday

@anil kharat1 I recommend you to debug this issue using the Access Analyser application. This application will allow you to find the ACLs responsible for blocking the user access. For more information, please refer to https://www.servicenow.com/docs/bundle/zurich-platform-security/page/integrate/identity/concept/acce....

 

Hope this helps.

0 Helpfuls

anilkharat
Tera Contributor
In response to Sandeep Rajput

Monday

@Sandeep Rajput  I’ve already checked their access using the analyzer, and all ACLs look correct. If this were an ACL access issue, it should result in an access error rather than a redirect to the new record form. The user is also able to see the record in the list view.

0 Helpfuls

anil kharat1
Tera Contributor
In response to Sandeep Rajput

Monday

@Sandeep Rajput  I’ve already checked their access using the analyzer, and all ACLs look correct. If this were an ACL access issue, it should result in an access error rather than a redirect to the new record form. The user is also able to see the record in the list view.

0 Helpfuls

Itallo Brandão
Mega Guru

Monday

Hi anil kharat1,

The behavior you are seeing (redirecting to a "New" form) is occurring because your Query Business Rule creates a mismatch between List Visibility and Record Accessibility.

The Root Cause:

  1. The List: Your custom Query BR forces the list to display records that the user technically does not have ACL access to (or modifies the query so the constraints are bypassed during the fetch).

  2. The Form/Builder: When you click the record, the system loads the Content Builder UI page ($streamline_content_authoring.do). This page performs its own canRead() check on the target record.

  3. The Mismatch: Since the underlying Read ACL still fails for that user, the Content Builder cannot load the existing data. Instead of showing an "Access Denied" error, the UI page fails gracefully by initializing in a "Create New" state (empty canvas), which is what you see in your screenshot.

The Solution: You should remove or disable the custom Query Business Rule. Manipulating the query to bypass "Security Constraints" is not recommended practice.

Instead, you need to satisfy the ACL (Access Control List) requirements for the sn_cd_content_base table:

  1. Debug Security: Impersonate the user, enable System Diagnostics > Session Debug > Debug Security, and try to access the list/record.

  2. Identify the Role: Check which Read ACL is failing. Usually, for Content Publishing, the user needs roles like sn_cd.content_manager, sn_cd.admin, or must be part of the specific Audience defined on the content record.

  3. Grant Access: Assign the correct role or Group to the user. Once the ACL passes legitimately, both the "Security constraints" message in the list AND the "New Record" issue on the form will disappear.


Hope this helps!

0 Helpfuls