Working with nested if statements in the logic of the calculation column of CHT XLSForms

Hello fellow community members,

I have an issue when working with XLSForms that use nested if statements in the calculation column. For instance, the logic used in one of the forms looks like the following snippet:
if(${bg_consent_equipment}='2', 'dm_unscreened', if(${rbg}<5.6 or ${fbg}<5.6 , 'dm_screen_normal', if((${rbg}>11 or ${fbg}>6.9) and ${dm_symptoms}!='no_symptoms', 'dm_untreated', if((${rbg}>11 or ${fbg}>6.9) and ${dm_symptoms}='no_symptoms', 'dm_susp', if((${rbg}>7.8 and ${rbg}<11.1) or (${fbg}>5.6 and ${fbg}<7.0), 'predm_susp', 'rbg_unclear')))))

Usually, the forms I work with are first tested with the ODK converter found here:, to make sure that the logic behaves as expected, however, when I upload the very same form in CHT, the form does not work as expected. Calculations that use simpler logic (like a basic if statement if(expression, valueiftrue, valueiffalse) all seem to work perfectly, however, there is always a problem where nested if statements are used.

Is there a special way to handle nested if statements in CHT x-forms? I find it very strange that the forms work fine when tested with the ODK converter but they behave differently in CHT.

Thank you in advance for your support.

1 Like

Dear @michaelmafantiri
There is a bug in the implementation of enketo in Community Health Forum. Empty variables are evaluated to 0. This has been mentioned here:

Looking at your statement, you might have run into the same issue. Could you check this?


Ok, I checked if we ran into the same issue you described above but actually the problem we have is different. I believe our problem is centered around how CHT evaluates boolean functions (if statements).

We learned from the CHT documentation that CHT apps support XPath from the ODK XForm spec, which is based on a subset of XPath 1.0. Then from the ODK documentation found here:, it says the boolean functions in ODK deviate from XForms 1.0 in that the 2nd and 3rd parameter are objects and not strings.

Based on this information above, could this be the real source of why simple if statements work well in CHT but the complicated ones (with nested logic) do not behave as they do in ODK?

Is there a special way to handle nested if statements in CHT x-forms?

In general, no, nested if-statements should function the same in CHT as in other ODK services.

That being said, the probable cause of the behavior difference between the CHT and ODK - XLSForm Online v2.x is that the CHT is using an older version of Enketo (as mentioned by @raf) while the service hosted out on is running the latest version of Enketo. There have been a number of bug fixes in the intervening Enketo versions (included the previously mentioned handling of unanswered questions). I am actively working to update the CHT to use a newer version of Enketo which should eliminate these behavior differences in the near future.

However for your calculation in particular, @michaelmafantiri, I am wondering what exactly is not working? Are you getting an error or is the calculation just not giving the expected result? I tried that calculation out in a test form on the CHT (version 3.13.0) and the nested logic seemed to behave as expected. The only thing I was not sure about was what type of question is dm_symptoms? (I used a string, but is it maybe a select_one or something else?)

1 Like

Hi @jkuester, thank you very much for your response, I am embarrassed to admit that the error we got has to do with exactly what @raf has already mentioned above; the enketo bug that evaluates empty variables to 0 in CHT and we are currently still applying the work-around of checking for empty variables in our logic, so that we can have the same expected behavior in both CHT and the ODK converter.

Thank you so much @jkuester for going into details and for testing the calculation logic I shared here. It helped us to go back again and pay close attention to all the variables in the logic, and what we found is that the variables fbg and rgb are mutually exclusive; one of them will be empty if the other one is set and this is what seemed to create a different behavior in CHT.

1 Like

@jkuester do you know the roadmap on when this will be fixed by chance?
I don’t like blowing up the logical expressions we use, and I wonder if this additional logical condition does not slow down the device.

@raf yes! The out-of-spec behavior for the empty number questions will be fixed in version 4.0.0 of the CHT. The tentative timeline for that release is the end of Q1 2022 (so in a couple of months).

We had originally hoped to ship these changes sooner, but decided to push them until the 4.0.0 major release since even small behavior differences like this might require changes in existing configurations (that were written with the assumption that unanswered number questions would have the value of 0).

@jkuester Thank you very much. We will migrate a bunch of flows in Q1 2022 and I am delighted to see that we will not have to rewrite the logic to deal with that.

Great job, thank you.