It looks like your ifElse statement is syntactically correct, and the functions you are using, such as ifElse, equal, getIndexValue, and number, are all valid for dynamic variables in Genesys Cloud scripts. However, the fact that you are consistently getting NaN, which stands for Not a Number, in both branches points to a few common pitfalls with how dynamic variables handle data types, lists, and indexes, and there are several things to check before concluding that the logic itself is wrong.
The most likely culprit is a simple typo or a data type mismatch, and your statement uses {{colExtension}} in the true branch and {{colExtentsionString}} in the false branch, so you should notice the spelling difference on the word "Extension" between these two variable names. If one of these variable names is incorrect, the function will not be able to find the list, which can result in NaN, so it is critical to double-check that these variable names exactly match the names of your dynamic variables, including capitalization. It is also worth remembering that in dynamic variables, expressions are evaluated in order, and the last value evaluated is what gets assigned to the variable. Additionally, you should confirm that your string lists actually contain values that can be converted to numbers, because you mentioned that you are converting decimal and boolean arrays into string format, and if any of those string values contain non-numeric characters, such as a currency symbol or a boolean value like "true" or "false", the number() function will fail to convert them and will return NaN.
If the variable names are correct, the next most likely issue is the selectedRecordIndex, because the getIndexValue function returns the value at the position specified by the index number, and in Genesys Cloud, list indexes are zero-based, meaning the first item is at index 0. If your selectedRecordIndex is 0, it will correctly get the first item, but if your logic expects a 1-based index where the first item is 1, you will be off by one. More importantly, according to the documentation, the getIndexValue function returns an error if the index number is equal to or larger than the size of the list, which means if your list has three items and selectedRecordIndex is 3, referring to a fourth item that does not exist, the function will error and return NaN.
Another point to consider is the data type conversion after getIndexValue, because the number() function is generally used to convert a string representation of a number into an actual number data type, but if getIndexValue on {{colExtension}} already returns a number, then applying number() to it might not be necessary and could occasionally cause issues, although it usually works fine. The real risk is in the false branch where you have number(getIndexValue({{colExtentsionString}}, {{selectedRecordIndex}})), because if the value returned from getIndexValue cannot be cleanly converted, for example if it contains a comma or a decimal point that is not handled correctly, the number() function will return NaN. There is also a known issue where the string() function can transform numbers with more than five digits into a decimal format with an "e+" notation, which might cause problems, but the number() function itself expects a clean numeric string.
To address this in a more robust way, you can start by adding some validation before your ifElse statement. You could create a couple of simple dynamic number variables to test if you can get a value directly, for instance by creating a dynamic number variable called testNumber with the expression number(getIndexValue({{colExtentsionString}}, 0)) to test if the first item in your string list can be converted to a number, and creating another dynamic number variable called testIndex with the expression {{selectedRecordIndex}} to confirm that this variable is indeed a number and not a string. In your false branch, you could also try just getIndexValue({{colExtentsionString}}, {{selectedRecordIndex}}) and assign it directly to a dynamic string variable to see what the raw value is, which can help you spot unexpected characters, and then you can decide if the number() conversion is truly needed, because if you are just using this value for display or comparison, you may not need to convert it at all. In the true branch, you are referencing {{colExtension}} directly, and if this is the list you are populating from a manual search, you should ensure that you are correctly populating it with number values, since the script editor does allow assigning results directly to decimal and boolean lists, so the values in {{colExtension}} should already be numbers. Finally, do not forget to check for any stray parentheses, because a misplaced parenthesis in a long expression can sometimes lead to unexpected results, and it has even been reported as the cause of a similar issue in the community.
By isolating each piece of the expression and checking the raw data, you should be able to identify exactly where the NaN is coming from and adjust your approach accordingly.
------------------------------
Camila Meneghini
------------------------------