Form Working fine on ODK testing but not when deploying on Kobo

I have authored a form that is working fine when I am testing on ODK - XLSForm Online
But, when I am uploading it on KOBOtoolbox, the form flow is a little messed up.

I have attached a picture of the form flow and the xlsx file. Please only look at the Survey tab.

After level 5 number concept, if the criteria are not met, then level 4 number concept should open, and if the criteria are met, then level 5 operations fluency should open. But level 3 number concept opens even ehen the criteria are met.

I think this is happening because in the condition
${grade_name} = ‘Grade 3’
${l4_nc_flag} = ‘False’

the part after the or condition is becoming true since the level 4 number concept is not opening therefore the l4_nc_flag is false by default, but why is that happening? As far as I remember, the value should be blank since the block is not opening at all (This I tested last year as well, and it was working fine).

But, the same file is working fine when I am testing this on getodk platform.

math_all_overhaul (1).xlsx (295.1 KB)

@shadsaiddiqui, when quickly scanning your XLSForm, I could see some emojis used in the form. Could you remove them to see if that helps. In the other hand, I also observed some formulas used in the choices sheet. Maybe just use the label instead of the formulas you have used under the choices sheet.

Hi @Kal_Lam , thanks for your response. I have been using emojis for a very long time, it never broke the form functionally before, but I shall try.
Same for the formula in the choices sheet.

However, I think I have narrowed down to the core of the problem. I don’t know if something changed when the KOBO toolbox platform updated recently, but the “calculated” fields that are using if-else ladder always get calculated to the else or “False” condition when that calculated field is not opened (due to being in an irrelevant group) or skipped. However, last time when I created this form, before the update, the calculated fields would just be “null” or “blank”. I was relying on the existing knowledge.

Seems like when I am testing this on the odk platform, it is still calculating the skipped fields as “null” and therefore the form is working fine there. Having realised this, I have updated my skip logics to explicitly use the values of the calculated fields rather than relying on the previous functionality where they would just be null.

1 Like