When a field hides due to Relevant other fields cannot see its value

[DougBrowning]

My purpose is to hide, or not let a user change, a certain value once they start filling out a repeat later in the form.

I have a question before the repeat of Forward or Backward.  This is used in calculations in a repeat.  This works great (was surprised if statements work on a constraint). So If(${field} = Forward, max-min, min-max)

But I want to make sure the user does not go back and change the value of Forward and Backward once they enter anything in the repeat.  I tried added a Relevant of count(${repeatfield}) = 0 and it does disappear once they enter a value in repeatfield.  BUT then all my If statements in the constraints start flipping to the else part instead.  I assume this means the Forward value is somehow hidden from the form once it becomes not relevant?  Is that value then lost?

If this is true any ideas on how to handle this?  I would calc into another field but then that will change values when the relevant goes off right?  I can't use once as they may change it.

Thanks

[Anonymous User]

Hi Doug,

Making a question relevant or not relevant does not just hide the question on the form, it removes the previously stored values. I think you are trying to use this configuration incorrectly. You should only use relevant statements when you do not want those questions answered, and you do not want values stored against them, ie they are not relevant to the survey.

If you make questions relevant and not relevant during a survey after the user has entered values in that question, by changing the expressions based on other answers, those previously stored values will be removed and when the survey is submitted, no values will be sent and/or the values will be updated to null in feature layer (if editing).

Phil.

[DougBrowning]

I am coming back to this as it has become a huge issue in our form workflow.  How do you suggest handling this?

Form has 7 fields that are all relevant as you go down the line.  So fill in 1 and 2 appears, etc.

Due to the way validation on constraints works currently if I put a bad value in field 2 it will let me continue filling out all the way to field 7 with no error.

User then taps add repeat and now the error on Field 2 is found.

The user wants to change the value on Field 2 so they first tap X (or backspaces) to clear the field.

Bamm! ALL of the data in field 3-7 gets instantly wiped out since my relevant kicked in (since field 2 is now blank).

    Note in my case there are not just 7 fields but 7 sets of 4 fields.  So the user actually just lost 28 fields of data!

What is the official way this can be solved?  Seems like a workflow hole to me.  To fix it I would again say we need a way to force validation on a field as they user leaves it.  We should be able to stop them from going any further right there.  The users are really after me about this one as every other forms program we ever had was this way.  Another possible fix is to somehow not kick off relevants on every single char change when typing.

In addition to this is constraints on relevant not being validated until form submit vs on repeat advance.  If my user has 50 repeats and hit submit it randomly goes back to say point 5 and says error.  Use clicks error in say field 2 and Bamm loses the entire repeat of data.  User does it all over.  User again hits submit and hits an error on repeat 12 and the whole mess starts all over again.

I am using a relevant like this string-length(${Lower1})>0.  Maybe there is someway to write this so that it does not disappear at 0?  Maybe I have to check all the fields below it also?  May get slow.  For lower2 relevant  lower1>0 and lower3>0 and lower4>0 etc.  That may work?

What about a validate page button like in Connect even.  But it right between the pages arrows.  

I am open to any ideas.  This one really scares me.

[Anonymous User]

Hi Doug,

As previously mentioned in some of our other posts and replies, we currently have a few known bugs with required and constraints not validating correctly in 3.3 release. We are aiming to resolve these issues in the next 3.4 release.

Based on your description above, this appears to be the root cause of your problem. If the required and constraints are validated correctly as they should, this would stop the user continuing on too far down the survey and hence when they go back and remove the value in the first question, the impact would not be as bad.

Changing a question from relevant to not relevant and removing the value stored is the correct behaviour and what is expected. In many workflows this is what is required/request by our users as going back and changing the first question or making it not relevant will change how the rest of the survey is completed, a different set of questions may be used, different lookup lists etc. So we can not store values for questions that are no longer relevant, and in you case the way you have configured your survey, clearing the value of the first question will cause all the other question to not be relevant and hence clear the values.

Phil.

[DougBrowning]

Phil are you saying that the next release will stop a user from going to Field2 if Field1 fails?  That is what the user is expecting but I am not sure Survey123 ever handled that.  If this did work correctly then relevant issue goes away.

I know I brought some of these points up before but not all of them.  Understand that 100s of people and millions of dollars are wrapped up in this issue, and they are all calling me, so it is not just a small inconvenience.  Telling them to wait for the next version, that has no timeline at all, is hard to get people to swallow.  Comments on here seem to down play this issue but really this bug disrupts the heart of the program and makes it unreliable and almost flat out not usable.

As others have mentioned when there is a core bug like this it really needs to be hot fixed and not stretched out months.  I love the speed you guys develop at but Core functions need to be made more important over new features.

Thanks!

[Anonymous User]

Hi Doug,

In regards to your comment "will stop a user from going to Field2 if Field1 fails" are you referring to constraints or required or something else?

Constraints should work when you change focus out of a field after entering a value, so if the value does not meet the constraint the user will be informed with a message when they move out of that field and the value will turn red.

Required can't be validated the same way, as if you haven't yet changed focus into that field, or the value is null, those are both acceptable outcomes while completing the survey, as the field may be needed to be filled in at a later time after saving to drafts, so the required check will happen only when you submit the survey or navigate to a new record if using repeats. You have previously requested an enhancement for page navigation required validation, which we have in our backlog.

We are aiming to resolve the 3.3 issues as soon as possible. In the past we have applied hotfixes to Connect and the App (recently for 3.0 we did 3 hotfixes and for 3.1 we did 1 hotfix). We are still working on the development of the fixes for the 3.3 issues, so whether they are hotfixed or in the next release, the same process has to be completed to resolve the issues properly. Due to the complexity of such functionality when repeats and nested repeats are involved, this can take longer than expected to ensure all other functionally is not impacted.

I know this doesn't help your current situation, however please know we are doing are best to get this resolved.

Phil.

[DougBrowning]

Thank you Phil for a more complete answer.  Not trying to be difficult but I have a lot of people counting on this when they leave for the field on May 6.  Hard to get app updates out there when people are offline for weeks at a time.  Just wanted to make sure it is in the works.

I am not seeing constraints work the way you say.  A constraint will not trigger right away on focus change if the field has a relevant on it however.  I think you may have said this is a bug?  But going to Field2 now for sure does not trigger anything if there is a relevant.  I have to hit next repeat for anything to happen.

thanks

[DougBrowning]

Forgot to say that for now I am using a once in the relevant and it seems to be working.  I am surprised it let me do that.

So this relevant will cause the field to appear when they first pick something for TopCanopy then later if they X the field it will not disappear on them.

once(${TopCanopy} != '')

Not sure if it will cause other issues but ok so far.