'Calculate' field type not compatible with if() function?

[MichaelOwens]

I have a series of calculated "test" fields (stored as either 0 or 1) that I am using in a nested if( ) statement to drive the formatting of a final 'text' field (Artifact Recovery Summary). The if ( ) statement logic and syntax works perfectly fine while the test fields are displayed in the form as 'integer' field types. This is shown in the first screenshot, as the formatting for when both values = 0, the calculation should return the text 'NCM'.

I want the test fields to be hidden in the form, and so I changed the field type from 'integer' to 'calculate'. When I make that one change and refresh the form, it appears to break the if( ) statement logic in the calculated Artifact Recovery Summary field. The result changes from 'NCM' to '0H -- 0P' which is not the correct formatting for that scenario (see second screenshot).

I don't understand why changing the field type from 'integer' to 'calculate' would do this. I am only trying to hide those fields from the survey form, as they only serve to drive logical statements in other fields. I also tried setting the field type to 'hidden' (which I technically don't want, because I don't want these data stored in the feature layer), and I also tried setting the bind::esri:fieldType to 'esriFieldTypeInteger' as well as 'null' and none of those changes made a difference either. I can only get this to work if I leave the test fields displayed as 'integer' fields in the form.

Any thoughts on why this is happening and how to fix it? Again, the if( ) statement logic and syntax is correct. There are no error messages being reported by the software for bad syntax. It just seems like a bug due to an incompatibility between calculate fields and using them in future if( ) statements.

I am using Survey123 Connect on Windows Desktop (Version 3.18.123)

Thanks in advance!

@JamesTedrick, @IsmaelChivite 

[DougBrowning · Accepted solution]

Common issue.  This happens because by default everything in 123 is a string in a calculate .

There are three options

First is Set the calculate field to int in the bind::type column.  This tells 123 to treat it as a int in the form.

Second, newer way, is use type integer then set the appearance to hidden.

Third way is to use the also new body::esri:visible column and just put a 0 in it and that will hide the field also. 

Hope that helps

[MichaelOwens]

I thought I had tried the first option and it did not work as intended. Second option works great though! I can leave the bind field set to null which keeps those logic test fields out of the published feature layer, but in the form they get treated as integers. Thank you so much @DougBrowning !

[DougBrowning]

Correct bind::type column sets the data type in the form and bind::esri:fieldType set the type in the feature service or with null leaves it out completely.

As @fklotz posted the 3rd way (I decided not to confuse my post and some old forms do not have this column) is to use the also new body::esri:visible column and just put a 0 in it and that will hide the field also.  Will add to my other post.

Glad it worked for you.

[fklotz]

I know that others may not agree, but I like to be explicit and I don't like how Calculate and Hidden Question Types return strings.  This is my method:

1. Use an Integer Question Type
2. Set bind::esri:fieldType to null so no field is created in the schema
3. use the body::esri:visible with a calculation to hide the field 
4. do not use the 'hidden' appearance (in the past I've seen this force a field in your data set even when the bind::esri:fieldType is set to null - this may not be the case anymore).

Benefits:

1. you have control over the field type
2. the calculation result is stored as a number, not as a string representation.
3. a field is not added to your database unless you want it to be 
4. you can change the body::esri:visible to see these fields during form development without accidentally adding a field to your data structure and without having to modify your calculate formula (so it no longer has to deal with strings)

A good resource: Survey123 Tricks of the Trade: hidden, relevant an... - Esri Community

n.b. I've not had a failure with bind::type in the past, so I don't use that method to try to keep the calculation result as an integer (or decimal).

[MichaelOwens]

Interesting... I will try it both ways and see what happens! Thanks for the insight @fklotz