Rules don't always seem to execute until after I save form

Hi Simon,

I assume by 'without saving' you're referring to having the new rule working in preview mode.

I've just created a new form (related to a blank list), thrown down some fields and tried a few different combinations and I can't find any that go unaffected by the rule (this is just in preview, I haven't saved). One for example is a Yes/No field that when ticked sets a text field to a certain value.

Would you be able to give me a specific combination you can't get to work as well as how you've currently got the rule configured?

Thanks,

Sam

Hi Sam,

Thanks for helping out with this.  When I say "without saving", I actually mean the record I'm adding using the nintex form after the fact.  I set up the form, I create the rule, and I Save and Publish the form.  Then when I go back to the Sharepoint list and click New, it displays the published form.  So far everything seems ok, but as I fill out the form, the rule based on the checkbox field does not seem to apply.  A different rule I have (using the exact same formula, but based on a choice drop down), works fine.  I'm confident the formula itself is fine as the one using a dropdown works, and also because after I save the record (taking me back to the sharepoint list), i can reopen that particular record and then the additional field is visible.  

I have included a screenshot of the formula:

In this case, the "AdditionalNotification" field is a Yes/No checkbox.  This particular rule is applied to a Recipient field which is obviously hidden unless the AddtionalNotification checkbox is checked (and hence = yes).  Again, if i check the box, and save the record, then reopen, it displays fine.  Its as if the rule doesn't recognize that the box has been checked until the data is committed to the sharepoint list (but again, if i change the AdditionalNotification to a choice dropdown, then it works fine when I select the appropriate choice).  

Hopefully that makes sense.  

Hi Simon,

I believe the problem here goes back to one of programming. Yes/No is a boolean value, so is represented internally by 1 or 0 (or in some cases true or false).

Testing your formula above with a yes/no checkbox I had the same issue as you even in a preview before saving/publishing.

Let me know if changing to the formula below resolves the issue:

AdditionalNotification!=true

Regards,

Sam

I tried that previously as well...  but the same issue. 

I think the code is OK either way, its just not kicking into action right away.  Just to show that (and to ensure there wasn't anything weird going on with my column) I created a new yes/no column called Notification.  I set the default to No.  On the Nintex Forms, I added the field, and then on the Recipient(s) field set the rule "Notification!=true" then Hide the field.  

I then Published the form, and from my Sharepoint list clicked New.  

When I checked off the Notification checkbox, nothing appeared.  I hit save to add the new record to the List.

Then I immediately opened that same record, and voila, the Recipients field is there.  But why doesn't it show up as soon as I checked it off?

I think went back to the Sharepoint List settings and changed the Yes/No to a choice dropdown with the Choices Yes and No.  I updated the Form and republished, then clicked New on the Sharepoint list.   This time, as soon as i select Yes from the drop down it appears immediately.  

Now, one interesting thing I noticed - If the default value of the drop down choice column is Yes, the field will show when i click New to create a new record.  Even if I change it to No, the changes won't take effect until after I save and reopen (essentially the same behaviour as with the checkbox).  However, if I set the default value as empty/blank, then the form works exactly as expected, and as soon as i select Yes the Recipient field appears, and then when i change it to No, the field disappears.  

Yes / No controls return true / false, so you can actually write that formula as:

!AdditionalNotification

Which would be the same as saying:

AdditionalNotification !== true 

Sorry to hijack this a bit but it almost sounds like you are using the the Column Reference in your Rule instead of the Named Control Reference. 

If the Rule you are running is only representing the state that would match what the Column's current value actually is (in sharepoint), then that is an indication that you need to reference the actual named control when you are setting up your rule. 

I figured it out.  It finally clicked when I was writing that last reply to you.  I went back to my column list and changed the Choice to only one - "Yes" (I could probably keep the No option, but its somewhat redundant), then the key was to make sure the default value was blanked out (ie. no default answer).  

The rule remained as Notification!="Yes" with then "Hide" just as before.

This time it works fine. 

So I think I was missing the empty default value.  It needs to be blank. 

Earlier when i used the Yes/No checkbox column type, the default answer had to be either  Yes or No - it could not be empty.  So the default display was based on that default value.  But when I forced no default value, it responds correctly.

Thank you Samuel for all your help on this!  Walking through it all to explain it was what I needed!   

I was a little unclear about the difference between the Item Properties and Named Controls as I noticed the column named appeared in both.  Your explanation clarifies that - thanks!

I did try using both of these in the rule, but had the same result - unless I specified a blank default value, it doesn't seem to work until after the save.  

Gotcha.  I may play with that in the future...  but for now it works, so I don't wanna touch a thing!  Haha.

Thanks for you help!

I'm glad you worked something out, although it still confuses me that Yes/No checkbox isn't working. I've tried my own solution, published and opened the form and it works fine on my side.

I made a new list with a 'single line of text' field called Recipient and a Yes/No checkbox (default of 'No') called Notification.

I then opened Nintex Forms, the fields were there by default as I made the list columns first. After that I just applied the previous rule to Recipient (When: Notification!=true  Then: Hide), published, pressed new and on the form it doesn't show Recipient by default as expected. Then as I toggle the checkbox it hides and shows as expected.

I think as nmarples says, there may well be something incorrectly linked here.

On the rule side of things !="yes" is okay for a single choice version as these are stored as text, however I can't get that to work on a yes/no checkbox. It has to be true/false or 1/0 on my side.

Yeah I saw a couple of older posts with the same instructions (which is how I started trying this), and they claimed it worked as well...  but they were all using an older Sharepoint, so I thought maybe that had something to do with it.  Its very possible I just picked the wrong variables.  Might test it out a bit more tomorrow.  

I have another issue on another list which has similar symptoms.  In this case, I have a master Sharepoint list of approved contractors along with an approval expiry date.  On a second Sharepoint list I want to lookup the list of contractors (simple lookup column), then display the corresponding expiry next to that.  Simple enough in a standard Sharepoint List, but in Nintex, the only way I could find to do this was to add a calculated value.  I found a post on this site that had a similar Formula, so I modified it to use the correct List, Column name, variable and Target column.  

Much as with my earlier problem, the Expiry date will not appear...  unless i save the record, then reopen it.  Then it appears.  Taking your advice, I verified that I was using the correct ContractorName variable - when I use the one from the Named Controls list, it doesn't work at all (even after saving and reopening), however, if I use the Item Properties variable it does work after the save.  

Any ideas on what might be causing this? 

That value, ContractorName, how are you getting that? Is it being populated in real time, or has it already been set previously? 

This is a really odd set of problems that you seem to be having. 

I could understand if you're basing your formula (on the calculated control) off of something from the Item Properties instead of the Named Controls because Item Properties represent the current state of the column on the item, while the Named Control values are represented by whatever the user has selected on the form in real-time. 

If you are setting your ContractorName in such a way that it's not being calculated in realtime, then any formula that is dependent on that value (ContractorName) will always kinda be one step behind. 

Maybe pictures will help. 

I'm going to make a simple Yes / No Column on my list: 

I can place the List Column Control onto my form using the built in Control:

And now I can make (2) Calculated Controls. They are both going to be setup almost exactly the same, only one will pull from Named Controls, while the other will pull from the Item Properties. 

Here is the 1st one: 

Here is the 2nd one: 

Notice how BOTH of those formulas look identical! Despite that, the information that they are referencing is completely different. While the Named Control will reference the value of the Control here on the Form, the Item Property will only reference whatever value the column named for the current item has right now... In otherwords, it's pulling the same value that you would see if you were to just look at your actual LIST!

To show this you can see how a NEW form looks with the above controls: 

It looks like EVERYTHING is set to false, but if I check that box...:

Now you can see that there is a difference. The DEFAULT value of the SPYesNo column (as shown in the first picture) is set to No. So whenever you create a new Item, that's going to be the value of the Item Property! However, the value of the SPYesNo FORM CONTROL is whatever the user has set it to in real-time, and if you change it, all formulas depending on that data will update accordingly. 

The thing is though, in that last picture, if I were to SAVE that item then the next time I open it, here's what it looks like: 

Because the SPYesNo FORM CONTROL is LINKED back to the column, when I saved it, its "checked" (or - true) value was SAVED to the Current Item's Column. Therefore when I open the form anew to edit it, the calculated control that is referencing that Item's Property will reflect that current value as shown! 

You should be able to perform a similar test using Calculated Controls to confirm that this is the way it works. While it might just be an Office 365 thing, I can't imagine that it would work so differently than the regular On Premise Nintex Forms... If it does, then maybe it's time to open a ticket and see if something didn't install correctly, or if it's just actually the way that it is. 

I hope that this helps. 

I do indeed seem to create an odd set of problems.  Undoubtedly my lack of experience with Nintex. 

I recreated the same column and controls within my form.  They perform the same way, with the exception that while the Named Control returns true/false, the Item Properties returned 1/0. 

I went back to my rule to ensure I was using the Named Control variable and that my sharepoint column was a yes/no checkbox with a default of no.  Still the same result.  It behaves the same way the Item Properties variable would behave. 

I then changed the SharePoint column to Choice (with only one choice of Yes), and set it to checkbox.  I updated to formula to "yes" instead of true.  This time it worked fine.  There seems to be something else I've either done in error, or something in my environment that is impacting this.  Ultimately this is not a big deal as I have it working with the blank default workaround.

My more pressing issue now is the lookup problem I'm having on another List.

I created a column called "Contractor Name", which looks up the column "Contractor" in a separate list called "Contractor Master List".

I then added a Calculated Value and used the lookup function, calling the ContractorName variable from the Named Controls. 

I then published the form and tried selecting a Contractor, but no luck.

Even after saving, no luck.

When I switch the variable to the Item Properties version, it works, but only after the Save (as expected based on your previous explanations).  So why does this not like the Named Controls variable?  Is the lookup function even the proper way to do this?

Do me a favor. 

Let's just see if we can at least get the value into a calculated control 1:1. 

Make a new calculated control and set the formula to just contain a reference to the Named Control: ContractorName

This should at least show you, immediately, whether or not you're even getting the current control's value. When you change the value of the ContractorName control, it should immediately update our test Calculated Control with the same value. 

Showing that would be a good start in the right direction maybe. 

Here's my new calculated control with the simple formula =ContractorName (using the Named Control variable).

It returns a result immediately, which is very encouraging. 

But where does the "1;#" at the front come from?

I tried selecting some other contractor names and noticed the first digit represents the position in the list.  So in my previous example that's literally the first company in the list.  If I pick the 75th company in the list, it would start with "75;#" then the company name.

I wonder if those extra characters are in effect changing the name used in the lookup, hence no matching expiry date is found?

OHHHH

You're using a LOOKUP Column for Contractor Name

All lookup values are returned with their ID value in front. 

You should be able to get rid of that by first parsing the values using the following formula: 

parseLookup(ContractorName, true)‍

Now when you use the lookup formula in the Calculated Control, it'll look something along the lines of: 

lookup("Contractor Master List", "Contractor", parseLookup(ContractorName, true), "Expiry Date")‍

(it should be noted that you'll need to replace all 'ContractorName' references with the actual references as copying and pasting from here won't actually do anything ) 

Give that a shot. 

Genius!  That did the trick! 

Thank you!!

excellent! I would also use the approach of the Calculated Control with a single reference as the formula to work through that other Yes/No problem if you're still interested in getting to the bottom of it. 

Seeing which value it is returning outright might provide a vital clue as it has in this case. 

Glad to see that it worked! 

@MegaJerk Thank you so much!  We need your reply to be marked as the solution.

I had a similar issue; was using a radio button selection, but in essence, the rule did not appear to fire until actual list item entry was saved.

• I changed the rule from using "Item Properties" to now using "Named Controls" (did not even see those initially) an all is well. :smileyhappy: