Skip to content

Nintex – Replacing a Decision Control with Save and Submit Buttons on a Flexi Task

If you’ve got a Flexi Task that has non-standard outcomes (or more than 2) and you want to replace the Decision Control with buttons that submit the form and sets an outcome, you can do so with just a little bit of configuration and JQuery.

The following describes how this can be easily accomplished:

On our Nintex Form, add a Decision Control, we will be using JQuery to hide this field (if you don’t want to use JQuery you can place it behind another control). Note that we can’t set this to Visible: No , because we will need the control rendered into the form.

Next, add ‘Save and Submit’ buttons to your form (one for each outcome). In the advanced section of the control’s properties, set the onclick of the first button to:

NWF$('#'+myDecisionControl+'_0').prop("checked", true);return;

This will submit the task with decision set to the first outcome. For the other buttons that you’ve added, change the _0 part to the zero-based value of the decision control (if you want the third outcome use _2, if you want the 8th use _7,etc). Note that the “return;” allows the form submission to continue after setting our decision.

To hide the Decision Control from the user’s view, we now want to add our JQuery.


It’s as simple as that. Now that’s great, but what if we want to be able to save this item mid-task and complete it later? Well if we just add a save button users will get a “This is a required field” error. The easiest way to solve this is by setting a ‘default’ on our control. Unfortunately, we’re not able to do this directly on the control, so we’re going to need some more JQuery. Luckily, we’ve already written it.

NWF$('#'+myDecisionControl+'_0').prop("checked", true);

Will set the value just like our buttons do, and since we’re not submitting the task when we perform a Save action, the decision set on a task mid-task shouldn’t matter.*

Those last two lines of JQuery need to be called after the controls are loaded, so by throwing them in a document ready, we get the following:

 NWF$('#'+myDecisionControl+'_0').prop("checked", true);

With that, we’ve successfully interchanged the required Decision Control for some more meaningful buttons.

It may matter if you’ve got filters on your Workflow Tasks lists to display these to users. Consider adding an addition Workflow Task outcome ‘Pending’ as your first outcome, then simply don’t have a Save and Submit button setting this Decision.

Why do it this way?

Another way to achieve a similar result is to connect the button to the Decision field, the problem with this is that the integer that you want to output as the decision (the IDs of the outcome) might not be consistent across your environments/Site Collections, especially if you are using custom task names throughout your farm. What this means is that for each new environment, you would have to publish the form with a calculated field displaying the ID of the decision you’ve selected or check the database to ensure the integer is consistent (note that previewing does not work, all values may simply display -1). If the integer is not the same, then you have to have different forms for different environments, which can be cumbersome and difficult to maintain.

Originally posted by Anthony Sopkow at That Must Have Been Somebody Else.