Skip to main content

Have you ever wanted to create a Form Rule based on whether or not your form was in New, Edit, or Display mode respectively?  It turns out you can do exactly that without too much effort.  In this example I will show you how to create a Validation Rule to throw an error on the form if the user selects a date that is in the past, but only while the form is in New mode. Let's jump right in!

 

First create your form and drag a date picker control onto the design surface: in this case we'll name it EndDate.

 

Next let's add a Validation Rule to the EndDate control as depicted in the following:

FormnRule.png

By using the formula builder (next to the condition box) I was able to select "Is New Mode" from the Common tab.   "Is New Mode" return true if the form is in New mode and false otherwise. "Is Display Mode" and "Is Edit Mode" are also available under the Common tab.

FormulaBuilder.png

We complete the rule by checking if "EndDate" is less than "Current Date".

 

Note: EndDate was selected from Named Controls tab and Current Date was selected from Common Tab in the formula builder, respectively.

 

Here is the entire rule: (Is New Mode) && (EndDate < Current Date )

 

We can read this as   IF the form is in New mode AND the EndDate control has a date prior to the Current Date then throw a validation error message.

 

Test the rule by selecting a date in the past while in New mode and you will end up with something like this:

Error.png

Next open the form in "Edit" mode by selecting an existing list item and you'll be able to choose whatever EndDate you will like without receiving a Validation error.

 

This is good stuff, no doubt - and allows you to make edits to existing items in Edit mode where the EndDate would otherwise be considered a "past" date and restricted by the rule.   You can disable the EndDate control on the form while in Edit mode by applying an "Expression" under the Appearance section of the EndDate control's configuration page.

 

With Nintex Forms you really can have the best of both worlds.   Until next time!

Very good explanation Mike, Thanks !

Is this the same method I can use for having a user in a certain user group say "Sales" and for example a Status = "Desk Processing" not able to edit certain fields after he submitted the Form?

Regards

Jaap


Yes, you could check if the user is in that specific user group with runtime functions and check the form mode to deactivate the control but this kind of validation shouldn't be made via form rules. The user would still be able to edit the list item using quick edit mode of the list (and this way doesn't use your form).

Preventing users from editing list items should always be ensured via permissions.


Thanks Enrico, makes sense,

You think there is a way to use 2 different layouts like I have shown below, say based on status and user role?
Or should it be 1 Form definition but using different panels or repeating area's to show details and editable details as per requirement? In the below example you see 2 rules, the first one executes and tests for user membership of Admin group (example) and the next one is the default input Form. Images are uploaded in the wrong order :-)

Form B Columns (Def 2)

Form A Columns (Def 1)


Reply