List collector variable issue

[Vengadeshgiri]

Hello All,

Im facing some issues with list collector variable and getting some error :

"Error MessageInformation could not be downloaded from the server because the transaction was canceled
Transaction time: 15,565ms
Reason: maximum execution time exceeded"

Actually this is on hardware table it may have lakhs of records, and I used reference qualifier that is based on other variable. So Hidden this field on load but still this exeuction error is coming

Does anyone have any idea

Regards

Vengadesh

[Tanushree Maiti]

Hi @Vengadeshgiri 

This issue I have faced before.

Filter the List collector in Ref Qualifier. The table which you have referenced , there are lots of data. Loading of all data taking time and getting failed.

Filter it properly. It will work fine.

[Vengadeshgiri]

Actually I have two static filter query like 

state and substate and one more query based on stockroom

So I hidden that field if stockroom is empty 

 So probably this will work on change of the stockroom

But the issue is with onload itself

[Ankur Bawiskar]

@Vengadeshgiri 

it's because the data is huge and filtering is applied

try to narrow down the search result to avoid timeout

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[onkarshivgan]

Hi Vengadesh, This usually happens when a List Collector variable is used on a table with a huge number of records, like the hardware table.

1. List Collector with large tables
List collectors don’t work well with large datasets. Even if the variable is hidden on load, ServiceNow still tries to fetch the data in the background, which can cause the maximum execution time exceeded error. If possible, try switching to a Reference variable or a Lookup Select Box, as they perform much better in this scenario.

2. Tighten the reference qualif
If you need to keep the list collector, make sure the reference qualifier is very specific. Try to filter the records as much as possible using indexed fields so the query doesn’t scan too many rows.

3.Custom approach for better performance
For very large tables, a better option is a custom solution using a Catalog Client Script with GlideAjax. This way, you only fetch the required data based on user input instead of loading everything at once, which helps avoid timeouts.

So the issue isn’t really about the variable being hidden, it’s more about the amount of data being queried. Adjusting the variable type or approach should help.

Hope this helps.