After my initial two posts on the subject (refer to Part 1 and Part 2), I never expected that my series on strange issues in Flow Designer would continue, and I'm asking myself: Is it really true that I am always the first to stumble into such traps? This time I struggled with the processing of GlideList values. Here's what I dealt with and how I fixed the problem.
My use case was building a simple Flow Action that calculates the difference between two lists of Sys IDs with the help of the API ArrayUtils.diff(). The underlying business requirement: I wanted to check if all the skills in the available skills list of an FSM agent are also in the required skills list to process a Work Order.
The resulting Flow Action is straightforward:
As shown in the top right corner, the required input variables are in String format to handle the list of Sys ID separated by commas, which serves as the underlying storage format of a GlideList field.
However, the Flow Action did not work, despite the same code working properly in a standalone script. Therefore, it appears that the problem is with the data itself and not with the code. To provide a clearer understanding of the issue at hand, I switched to my PDI and replicated the scenario there.
I have implemented an even more simplified Flow Action that logs the content and data type of the passed GlideList value:
(function execute(inputs, outputs) {
var _strListOfSysIDs = inputs.list_of_sys_ids;
gs.info('Value of "_strListOfSysIDs": ' + _strListOfSysIDs);
gs.info('Type of "_strListOfSysIDs": ' + (typeof _strListOfSysIDs));
})(inputs, outputs);
I then built a minimal Subflow that expects a Work Order record that brings the list of required skills stored in a Flow variable "Skill List" of type String. This approach aims to retrieve the Sys IDs as a String-based value:
In the next step, that Flow variable is passed to the previously created Flow Action:
I was curious to see exactly what the data passed to the Flow Action looked like:
At first glance, everything seems to be correct. You can see a list of Sys ID, which is passed to the Flow Action. However, that does not match the output from the syslog:
What is going wrong here?
If I pass the value of a GlideList field, why do I see something like "[object GlideRecord]" as a value? Where have the Sys IDs disappeared to?
So I took a closer look at the execution log of the Flow. And then I noticed that the Sys IDs are linked and provided with an info icon, which I found quite astonishing, because I wouldn't have expected the Flow Designer to understand simple String values that well. And that is precisely the problem. Values from GlideList fields are not returned as a string of comma-separated Sys IDs, but as something else. Probably as a fully initialized GlideRecord object that you can then iterate over (to be honest, I haven't wasted any time finding out that).
The really amazing thing, however, is that there seems to be no data type checking at all. Both the Flow variable and the input variable of the Flow Action are defined as type String, yet ServiceNow writes objects to the variables without any error messages. This has serious implications for future development, as I can no longer rely on the data types defined in a flow!
Back to the problem: For performance reasons, I don't want to trigger another database operation, but simply want to return the value of the field. I experimented a lot and finally settled on a workaround where I use an inline script to get the field value instead of using a data pill as before:
After the next test execution, everything now runs like a charm, as we can see a real String value inside the Flow variable "Skill List"
And also the Flow Action recognizes the value as a String type and can continue the execution as expected.
Have you ever encountered a similar problem? If so, what was your workaround? Please feel free to leave a comment and share your experience with us.
