Design consideraton of Scripted Filters in PerformanceIssue Scripted Filters is a feature that provides coding support when filtering records in Lists. The explanation of the feature can be found in our Product Document via below URL: https://docs.servicenow.com/csh?topicname=t_ScriptedFilters.html&version=latest While this is a versatile feature, it has certain limits that need to taken into consideration in designs. This article aim to highlight the limitation in terms of Performance. For example. There maybe requirement to filter on the 'Configuration item' field by dynamically loading specified data from the CMDB Hierarchy. In such requirement, an immediate thought can be building up a Scripted Filter with below codes: var answer = []; var cmdbGr = new GlideRecord("cmdb_ci"); cmdbGr.addQuery(<condition>); cmdbGr.query(); while (cmdbGr.next()) { if (<condition>) { answer.push(cmdbGr.name); } } return answer; However, this filtering script can lead to significant impact in list rendering in terms of time and memory consumption when there are millions records in the CMDB Hierarchy. The rationale behind not only lies in the large amount of data the script needs to access, but also the limit of the platform that it has to call the script for multiple times, 4 - 6 times typically, during the list rendering. Users can experience significant slowness when accessing the corresponding lists when loading with such filters. They may face the UI Time out error in some extreme cases when the rendering time exceeds the UI Transaction Quota (298 seconds by default).ResolutionTo avoid running to any performance issues in using scripted filters, it is crucial to keep these scripts simple. One way to determine the complicity and time consumption of these scripts is to test them from System Definition ==> Scripts - Background. This feature shows the time consumed by running the scripts so that you will be able to tell the anticipation when the scripts are used in Scripted Filters. Always remember to multiple 4 or 6 to the reported time from Scripts - Background to make the estimation more accurate. Also, if there are messages like 'Large chunk of data is about to be streamed' appear by running the script, it means the memory consumption is high. If the script is found slow or using lots of memory, it will be better to split the filtering logic into ACLs or Query Business Rules on the target table. With the above example on the CMDB Hierarchy, ways can be considered are converting the whole filter logic in an ACL if the filter condition is purely on Users, Roles, and/or Groups. Query Business Rules are another candidate to dynamically add the necessary query conditions with the potential of reducing time & memory consumption as they may use the 'current' object therefore eliminate the need of looping through the whole table.