+3
Hello!
I need a validation rule to make a text field (Describe Error Type) mandatory when a box (g. Other) is checked on a multi-select.
Here is my validation rule - invalidate when the error type contains "g."
Unfortunately, when I publish this, the form won't allow me to save when the field is populated.
What am I doing wrong?
Thanks!
+14
It won't validate because you're code is saying:
Invalid when, ErrorType contains "g"
so... when you click on the Error Type of "g", you have now made your text field invalid!
To get to where you wanna be, you'll need to add a second half:
contains(ErrorType, "g") && isNullOrEmpty({YourTextBoxControlName})
If you did that you'd be saying
Invalid when, ErrorType contains "g" AND {YourTextBox} is empty
Now your TextBox is allowed to be empty (or populated depending on your other rules) when any other ErrorType is selected, but NOT when "g" is selected.
Hope this helps!
+3
I appreciate the response. I tried that, and get the same result; unable to save because field is still invalidated despite the text field "ErrorTypeOther" being populated. I've created a support case with Nintex as I feel this is a defect.
+14
Yeah... that's pretty wild. Out of curiosity, if you were to make a new form with the same general setup (of just those two controls), does it work?
I only say that because I remember a long time ago I once deleted a rule in a way where it "looked" gone but hadn't actually be removed from the control, so it was still being flagged as invalid, even though it wasn't.
(I've seen similar with forgotten validation rules that are set via the Control's Settings and not by way of the Rule panel)
Any who, if this ever gets solved, I'd love to hear a follow up as to what was causing it!
+3
So I figured out a weird nuance: when building the formula, we have to select from Named Controls instead of Item Properties and it appears to work correctly (even though they are identical in the formula builder), and used {Self} instead of the control name. I met today with a Nintex rep and he pointed me in this direction. We now have a disparity on the validation behavior between NewForm.aspx vs EditForm, and he's spinning that up internally.
So, for interested parties, use Named Controls when building formulas!
+14
Ah yes. Been there too. It's not entirely obvious at first, but you only need to make the mistake once to learn that lesson the hard way!
Sorry it was your time to find that particular mine.
At least it's fixed, but that new issues sounds like a real piece of work. If I'm reading correctly, the Edit Form (messing with a previously saved document) is still pointing towards the actual Item Prop instead of the Control Value, whereas the New Form is correctly pointing towards Control Vales?
Did I get that right? if so, whew! Hope they can work something out for ya.
+3
Logic is same on both New and Edit, but there's a bug that the validation doesn't trigger on New unless other options (of Error Type) are checked. Edit doesn't have the issue, but logic is same. The question, of course, is why is the validation functioning on Edit but not on New? Hopefully we'll learn more soon.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.