There are several ways to filter a List collector dynamically. This is the simplest one I found so far. It will work in both the Service portal and the default interface. It will only require a one-line onChange client script for it to work on the default interface. Let’s see it with one simple example.

If you try to populate a GlideList field using a script, you can end up with different values in your table, depending on the way you do it. GlideList fields such as the Watch list and Work notes list can store 2 types of values: Users (sys_ids of Users in the sys_user table) Emails Usually,

Why don’t we use Field styles for X?Unluckily, this is probably the most inconsistent piece of functionality in the Servicenow platform.

Servicenow provides a good documentation page about User Notification Preferences. Have you ever wondered where these settings are stored in the backend? Let’s have a look at the main tables and fields where Servicenow stores this data. Notification Preferences Notification Preferences Popup Backend Table / Field Allow Notifications User -> Notification [sys_user.notification] Notification Channel Notification

Replacing Processors with REST Servicenow decided to ban the creation of new Processors. Luckily, we can still do the same (in a more complex way) using Scripted REST APIs. State vs Incident State Why are there two fields storing the same data? Both fields are synchronised with Business Rules and the values are the same if

The autocomplete-servicenow package for Atom received the last upgrade for the Quebec release. I have stopped updating it as I no longer use Atom. Check the Readme section in the Package page or the Github repository to see the prefixes and APIs available. Atom Package: https://atom.io/packages/autocomplete-servicenow GitHub Repository: https://github.com/rubenferrero/autocomplete-servicenow Package Installation Open command palette in Atom: CMD-SHIFT-P (macOS) or