List Collector field with cmdb_ci table taking too long to load data.

[Namita_Snow]

Hi everyone!

I'm currently working on a requirement, where we need to show cmdb_ci data in a list collector variable. I'm using on change client script and script include to filter the data based on the choice selection in another variable.

But currently the variable with cmdb_ci data takes more than one minute to load the data.

Please let me if there is any way to improve the data loading.

Thanks in Advance!

[Nikhil Bajaj9]

Hi @Namita_Snow ,

Since Cmdb_ci is a heavy table with lots of data (being Parent table of all CI tables) so it always takes time to load. It's a normal behavior, to cross verify write - CI Class manager in Filter navigator and see the load time.

 Better way to use any reference qualifier or filter to naroow down the data.

if my answer helped you, please mark it solution accepted.

[MackI]

hi @Namita_Snow

You're encountering a common challenge when dealing with large datasets like cmdb_ci in list collector variables, where complex filtering or retrieval can lead to prolonged loading times. The ServiceNow product document reference related to ITSM and CMDB provides several strategies and considerations to enhance data loading performance in ServiceNow, particularly when working with Configuration Items (CIs) and related data.
Here are ways to improve the data loading for your cmdb_ci list collector variable:
1. Optimise Script Include Logic and Queries
The efficiency of your script include is paramount, especially when querying the Configuration Management Database (CMDB), which can be extensive.
• Refine your queries: Ensure that the GlideRecord queries within your script include are as specific as possible. Filters for the same fields evaluate as an AND condition, while filters for different fields evaluate as an OR condition. A well-structured query can significantly reduce the number of records the database has to process.
• Avoid inefficient operations: Review your script include to ensure it doesn't perform unnecessary calculations or complex logic that could be offloaded or simplified. For instance, scripts related to state transitions or UI elements, if not optimized, can impact performance.
• Consider limiting results: If the user doesn't need to see all possible CIs initially, your script could implement a limit on the number of records returned. An example is seen in the MyCustomUpcomingLinkProvider_ChangeTask script include, which sets a LIMIT of 10 records to display upcoming tasks. This approach could provide a faster initial load, with options for the user to refine their search if needed.
2. Filtering and Limiting Data Scope
Reducing the overall scope of the data being processed is a key performance enhancement.
• Utilise specific filters: When defining conditions in your client script or script include, use highly specific filters to narrow down the cmdb_ci records. For instance, in other contexts like reconciliation or machine learning models, narrowing the scope (e.g., by specific publishers or timeframes) leads to faster results.
• Leverage Principal Class filtering: The Principal Class filter functionality is applicable to new customers and can be used to filter CIs based on their class. This can help narrow down the selection of CIs by specific types (e.g., Linux servers).
• Optimize related service identification: If your cmdb_ci data involves related services, ensure the change.conflict.populateimpactedcis property is set to true. When enabled, the ChangeUtils script include uses the svc_ci_assoc table for faster processing of impacted services, rather than traversing the CMDB tree structure, which is slower. This is especially crucial if dynamic CI groups are used.

3. Leveraging Asynchronous Processing and Batch Updates
For operations involving a large number of records, processing them in the background can prevent the UI from locking up.
• Asynchronous refresh of impacted services: If the list collector is triggering a refresh of impacted services or CIs, consider setting the com.snc.change_request.refresh_impacted.event property to true. This runs the refresh process in the background via an event, and you receive a notification upon completion, preventing UI delays.
• Batch processing for multiple record updates: If your client script or script include is designed to update multiple records, consider implementing batch processing. The Multiple Record Associator (MRA) component and the RelatedListIncidentItemUpdateHandler script include are used for batch processing of more than 50 records (e.g., child incidents, affected CIs, impacted services/CIs, or assets) asynchronously in the background, significantly improving system performance.

4. Configuring System Properties for Performance

ServiceNow offers system properties that can influence the performance of UI elements.
• ref_search_on_click UX page property: By default, empty reference fields in Service Operations Workspace only display recent selections instead of automatically searching and displaying all available system values. This design choice improves overall performance. If this property has been set to true (to revert to automatic searching), setting it back to false (or leaving it at its default, which is implicitly false for performance) could help.

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community.

[Shashank_Jain]

@Namita_Snow ,

If your list collector (cmdb_ci) variable is taking a long time to load, it’s usually because too many records are being fetched from CMDB (which can easily be in the thousands). Some tips to improve performance:

1. Apply a Reference Qualifier – Make sure the list collector is restricted by a condition or a dynamic filter option. Avoid loading all CMDB CIs.

2. Avoid Heavy Display Values – If you’re fetching related fields (like manufacturer, model, etc.), it can slow down performance. Only return what’s really needed.

👉 Bottom line: Don’t load the entire CMDB in a list collector. Use filters + GlideAjax + Script Include with limits to fetch only the CIs relevant to the user’s selection.

Hope it helps!

[Bhuvan]

@Namita_Snow 

Did you follow Client Scripting best practices,

https://developer.servicenow.com/dev.do#!/guides/xanadu/now-platform/tpb-guide/client_scripting_tech...

CMDB is one of the key tables in ServiceNow where number of records could be in millions for some customers and trying to fetch the CI details from a list collector could lead to performance issues. Carefully consider business criticality of the requirement and if possible, suggest alternate solution to the Client stakeholders as this is not best practices.

If this helped to answer your query, please mark it helpful & accept the solution.

Thanks,

Bhuvan