Skip to main content

Nintex Forms allows a Forms Designer to set conditional formatting and validation within their task form using the outcome values (Approve, Reject and the other custom outcomes) the form designer may have made in the Flexi-task action.

 

For information on how to configure the Formatting Rule, please read the following post: Using validation rules to ensure a comments box is not left empty

 

However, one question that comes up is, why is the Formatting/Validation rule written around an outcome equaling a number and not the value 'Approve' or 'Reject'?

 

For example, in a Nintex Task Form, you may see a Validation or Formatting Rule that looks like this:

 

TaskRule.png

Well, what is the '1' that we are talking about?  Why not the term 'Approve'?

 

In the Nintex Workflow Config database, you will find a table called 'dbo.ConfiguredOutcomes'. That table stores the Id as well as the associated Name for the outcomes used in the 'Decision' control of the Nintex Task Form.

 

table.png

dbo.png

When writing a Formatting/Validation rule on a Nintex Task Form, you will want to use the 'Id' of the appropriate outcome. You can also see the outcome by adding a Calculated Value Control to your Nintex Form, and assigning the value of the Calculated Value control to that of the Named Control 'Decision'. Once the form is used in a workflow, you will see the 'Id' number appear in place of the Calculated Value control.

Hi Marian,

it is a little late, but I have some answers for you.

This IDs are shared across different workflows / tasks. If you rename an outcome, a new ID/text gets created.

In my case, the IDs are not in the Config Database, they are in the Nintex_Content Database.

thanks Daniel.

Hi Guys,

I've just run foul of this particular feature. I have unit tests for variations of forms that are needed to scrape additional details in various workflow tasks. There are approval comment rules and some field validation rules should ignore null fields when the task is rejected.

After getting my customer to run through the unit tests and make sure all rules are firing as expected I then exported the forms to various Flexi-Tasks within a fairly complex set of workflows. Unfortunately due to this feature, what worked well in the unit test workflow fails when integrated into the pay dirt workflows. When I import these nicely tested forms into each location in the main workflows, the Decision values change. Where Approval in the unit test workflow equaled 1 and Reject equaled 2. In the main workflow Approval now equals 0 and Reject now equals 1. So none of the Rules based on Decision function when I Import an exported form into a new workflow and all the rules need to be updated when moved to a new location. 

I would posit that this feature needs some work as rules should not break because I move a form to a new or different workflow. I recommend changing this feature to something reliable such as if Decision.Text == 'Approval' which should work with controls that support enumerated type lists. There are other alternatives that can be built using javascript however what's the point of having a rules engine that has this feature.

I've scanned this site quite a bit but only find many other articles describing this problem but none describing a solution such as I have shown. 

how can i disable a field until form is not approved?

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings