---

XANADU EDIT: Unfortunately, the ‘Data Security Filter’ feature did not make the Xanadu release.

In this article, you will learn various techniques for removing the ‘Hidden by security constraints’ message from lists.

My most upvoted idea on the Ideas portal, ServiceNow’s ideation portal on the ServiceNow support site, is Ability to disable “Number of records removed by security constraints”… and results returned (you will need a ServiceNow support account to see this). ServiceNow’s implementation of security hides records that users do not have access to and gives the user the exact number of records hidden for that page of results.

Let’s say I have a user database with users from several companies:

My security model dictates that I can only see users belonging to the same company. I can realise this requirement by updating existing read ACLs, and the result is as follows for a user from ACME North America:

And with a larger row count:

The Problem

The Message

The Row Count

The message is only part of the problem. The first page of results only shows 20 records, while the user can see all users from ACME North America- 143. The list result and row count will be as if the records you cannot see are part of the list, which will often bury records you want to find on further pages. Sometimes, the first page of the results will be hidden entirely. In this case, the user must find the other records by scrolling through the six results pages.

This seems like a peculiar implementation of security to me—applying security after the query and pagination are completed. This has been part of the platform for as long as I can remember and has not been updated despite the importance of security in today’s software landscape.

Can we work around this “platform feature” to address the message and row count problem?

Solutions

There are a few solutions to the message and row count count problem. Let’s explore some of them, from least to most preferred approaches.

Change the UI message

Most messages in ServiceNow can be updated for localization by changing the words in existing UI message records. You can also use this to change messages to suit without modifying code.

As an admin, navigate to System UI > Messages and filter where Key is Number of rows removed from this list by Security constraints: {0}. Open the record and replace the message as desired. For example, you can set the Message field to “…”

Now the message is gone! (almost)

This solves the messaging problem but not the row count problem.

Alternatively, you can change the wording to something more meaningful:

This doesn’t really solve anything but might improve user experience.

Adjust your filters

The User example above removes users with a company other than ACME North America from the results page. By adding the filter Company is ACME North America, the message goes away.

This solution is not broadly applicable as you often will not know the criterion for hidden records to filter them out.

Add the ‘glide.security.ui.filter’ System Property

Someone from ServiceNow told me that a system property could be used to hide the message, but I could not find it documented anywhere. So, I asked ChatGPT:

in servicenow, what is the system property to disable “hidden by security constraints” message

Perhaps I should not be surprised that it hallucinated one that did not exist or work. I won’t repeat it here and add to the misinformation database that has become the internet and generative AI.

After some old-fashioned googling, I found a few articles referencing the glide.security.ui.filter system property. Setting this property to true disables the message and row count issue system-wide.

HOWEVER… I would advise caution when considering applying this solution. KB0818338 – ACL looping on ‘glide.security.ui.filter’ system property causing StackOverflow advises that using this as a global system property can cause ACL looping, resulting in a stack overflow. This readme Number of rows removed due to security constraint from 2020 also provides a cautionary tale.

Hi
I use this sys_properties in 2018 and the French team of servicenow told us that we should not use it.
The problem that we have got at that time it’s on the table sys_report when we want to go on it it have done an infinity loop wich is cause by an native acl on this table, they were not able to solved the problem and told us we should not use it and also it will do some performance issue…

idress00, July 29 2020

So, please read on.

Add attribute ‘glide.security.ui.filter’ to your table

If you decide not to use the System property above, you can remove this message/behaviour for any table by adding the glide.security.ui.filter attribute. This can be done on the User table by navigating to System Definition > Dictionary and filtering where Table is sys_user and Type is Collection. Open the Dictionary entry for the User table and select the Advanced view Related Link, then add ‘,glide.security.ui.filter’ to the Attributes field. Save to commit your changes.

I could not find official documentation on the functionality behind the apparent System property or similarly named field attribute. Given the known issues above when applying this functionality system-wide, I would advise caution. When applying any undocumented functionality to your instance, always contact ServiceNow support before implementing it in production.

Create a before query business rule

This is ServiceNow’s official solution to removing the observed security functionality, according to KB0682569

The solution is to define a onQuery business rule to limit the list so the limit will be applied before the ACL and then you will see a clear list without the “Security constraints” message. This will avoid confusion. 

ServiceNow, KB0682569 

This solves both the message and row count problems.

Before-query business rules have even been referred to as “the other access control” (KB0523826). But beware—the Scripted REST Table API does not respect before-query rules, so you need to implement your security in ACLs. Also, be mindful of performance best practices for Before Query Business Rules.

In my User company example, creating a before query business rule with the following code as follows solves our problems:

(function executeRule(current, previous /*null when async*/) {

	var myCompanyRecord = gs.getUser().getCompanyRecord();
	var myCompanySysId = myCompanyRecord.getValue('sys_id') || "";

	current.addQuery('company',myCompanySysId);

})(current, previous);

Wait until Xanadu release

The introduction of the Data Filtration plugin was hoped to solve this problem, but as of Washington, DC, the security constraints message remains even when using ACLs instead. Data filters still run after the query and pagination are made.

I have been informed that a new feature – Security Data Filter – is planned in Xanadu and is expected to fix this once and for all. Several other security enhancements were announced at Knowledge24, including ACL query rules and deny ACLs. I can’t wait to see the release notes for Xanadu!

TL;DR:

• Problem:
  • Message reveals hidden records, causing security concerns.
  • Row count issues obscure visible records.
• Solutions:
  • Change UI Message:
    • Modify text in System UI > Messages.
  • Adjust Filters:
    • Refine filters to minimize hidden records.
  • System Property:
    • glide.security.ui.filter can disable the message but may cause performance issues.
  • Table Attribute:
    • Add glide.security.ui.filter to specific tables.
  • Before Query Business Rule:
    • Apply filters before ACLs to solve message and row count issues.
  • Future Fix:
    • Security Data Filter feature in the Xanadu release aims to resolve the issue.