Filtering within Application Vulnerability Management
Calculators, and Assignment Rules use conditions during import, created using the condition builder. Changes to their criteria can affect performance since each record is evaluated using these filters.
The rules and calculators shipped with the base system are optimized for performance. Editing or creating rules or calculators takes care and may require both ServiceNow and Application Vulnerability Response expertise. That said, some guidance is available.
Avoid filtering based on subclass fields
Some tables support extension. An example of that is the CMDB CI [cmdb_ci] table. Tables like cmdb_ci_hardware and cmdb_ci_computer extend this table. If you filter based on a field that is not on the parent table, that filter can be expensive to construct and evaluate.
Condition filter drop-down menu example
For example, filtering on Configuration Item > Cost would not adversely affect performance because Cost is a class field, and not a subclass field, of Configuration Item.
Filtering on class field example
Configuration Item > Computer, however, is a subclass requiring a dot-walk to another field, in this case, Operating System. This process can take many milliseconds which add up quickly, when millions of vulnerable items are being imported, and affect performance.
Filtering on subclass field example
Note: Using the [contains] condition is like a wild-card search and can cause performance impact. Using [is], wherever possible, is more efficient.