NOW You Know: Updating the Filtering Logic of the ‘Add’ Button on the Affected CIs Related List

In ServiceNow, several tables, including Incident and Change, allow you to identify CIs that are being affected by the topic of the given record via an ‘Affected CIs’ related list. Some processes populate this list automatically, but additional CIs may be added manually through the use of an ‘Add’ button.

When the ‘Add’ button is clicked, the user is presented with a somewhat unique interface, provided by a UI page that ServiceNow does not give users access to manage. At the top of this UI page appears a “Configuration Class” field that determines the context of the traditional record filter beneath it. What the “Configuration Class” field is populated with when a user clicks the ‘Add’ button is conditional on several things, primarily what the class was of the CI that was most recently added to the related list.

Some organizations will want to modify this behavior as it could be disorienting to task fulfillers for the selectable CIs to be governed by a class filter with what, to them, may seem to be arbitrary factors. Some task fulfillers are not familiar with the CMDB class hierarchy and may only be able to identify a CI by other parameters, such as name, assignee, etc.

A baseline script include named AssociateCIToTask governs the functionality of this UI page, and modifying this will allow you to control the default filtering and configuration of what appears when a user clicks the ‘Add’ button.

If you refer to the above image, the text in yellow has been modified from baseline. In the original script, the “sysparm_table” parameter is usually determined and set programmatically according the class most recently selected for this related list (and other factors). Here, I’ve hard-coded it to be “cmdb_ci” so we start will all CIs being selectable. Additionally, I set the “sysparm_fixed_query” parameter to a filter based on a different script include that will automatically filter the list of CIs to only show classes that the organization has determined to be “in scope.” As an end result, users are reliably presented with a list of relevant CIs that is not beholden to the current record or otherwise filtered based on previous interactions with the related list.

To conclude, I should say that this particular use case may vary significantly by organization, so further modifications outside the scope of this article will require some investigation into the functionality of the AssociateCIToTask script include, but modifying that script include should be sufficient to achieve whatever result is intended. However, note that the UI page itself cannot be modified so, for example, the Configuration Class filter cannot (at time of writing) be removed entirely.