Skip navigation
All Places > Getting Started > Blog
1 2 3 Previous Next

Getting Started

420 posts

This blog describes how to enable "Document Generation" feature on SharePoint 2013 on-premise server.

Prerequisites: Nintex Live is installed and running on your farm.

  1. Go to Central Administration > Nintex Workflow Management > Nintex Live and external Settings
  2. Click on "Enable" next to "Enable prerequisite service" on top.
  3. Under Nintex Live heading, click on "Activate" next to "Document Generation capability" feature.

The above steps makes the "Document Generation" feature start and running.

Now, you have to add "Document Generation" workflow action to allowed workflow actions on your farm.

  1. Go to Nintex Workflow Management > Manage allowed actions
  2. Check/Select "Document Generation" workflow action.
  3. Click on "OK".

Now, make sure you see "Document Generation" workflow action available for use. For that, create a workflow and from workflow actions, type in "document generation" or go to "Lists and Libraries" category, you see the "Document Generation" workflow action available.

Sometimes we have disconnected data in our form that we do not require in the underlying list, but may need as part of our workflow process.

In this example I show you how to utilise the very helpful Form Data available in Nintex Workflow to pull information from the form that submitted the data in the first place.


List Settings

  • Custom list with title field as standard called "FormDataDemo"


Form Settings

  • Customise the "FormDataDemo" list using Nintex Forms
  • Add Single Line Textbox control to the form with the following settings:
    • Name:  UnconnectedTextBox
    • Connected to:  Not connected
    • Data type:  String
  • Publish the form


Workflow Settings

  • New nintex workflow on list "FormDataDemo"
  • Start when items are created
  • Query XML action:
    • XML source:  XML
    • XML:  {ItemProperty:FormData}
    • Output 1 - XPath:  /FormVariables/UnconnectedTextBox
    • Store result in: New variable "vTextUnconnectedTextBox"
  • Log in history list:  vTextUnconnectedTextBox



Of course you are likely wanting to work with that value, not just log it to history list, but this was just for demo purposes and to help resolve a question asked on the community.

Each month, we like to highlight valuable community members and name them to a monthly honor roll.  Just hover over their names and click "follow" or visit their profiles and follow them there to get their activity in your news stream in the community.


This helps expose you to how active community members are engaging with other Nintex users.  You'll see what content they're creating, and responding to.  It's a great way to enrich your community experience.


For October, we have a nice mix of new and existing community members.  A couple of call-outs:

Tom Castiglia is a long-time community member and Nintex Partner.  His answers to people's questions are always helpful, but Tom's also blogged a couple of times in just the last month. Visit his profile page and click "content." to see his blogs. Tom, thank you!


Vincent Cabral is the VP of Product for Nintex Drawloop. He's a frequent visitor to the community, answering customer questions. I don't think it's often that a VP at any company takes the time to interact with customers at the community level. I think it speaks to the person he is and the kind of company Nintex is.  Vincent, thank you!


Nintex Technical Evangelists have been creating great content for the new Nintex Product Blog. It's THE place to get the latest information the features and capabilities of the Nintex Workflow Platform. Many thanks to those listed below! Follow these guys!


And thanks to customersRamana Thakkallapally and Clavin Fernandes who've been members for about a little while, but recently dove in to provide some really helpful replies. It's a perfect example of community give and take.


See the entire list below. Thank you all for your answers and contributions to the Nintex Connect community!


This month's Honor Roll members to follow:


Congratulations and thank you to all of this month's Honor Roll members!


honor roll big


Honor Roll members will get this badge in their reputation center, along with 100 points.


This is not just open to the whims of the community manager! If you'd like to nominate someone for the honor roll next month, send me a message: or ping me via the community!

Though I have been working with Nintex Forms and Nintex workflows for a long time I didn't happen to realize how versatile and fun to work with repeating sections on the forms in conjunction with Nintex workflows. Long story short, I always had this common requirement from Infopath form days till a new project I implemented purely with Nintex, that is none other than having an ability to report and update the repeating table rows using spreadsheet view in the SharePoint.


Until I come across a great post written by Vadim Tabakman parse repeating section data I felt it is not possible help clients with such requirements without code, but Vadim Tabakman's posting changed the way how I looked at NIntex Forms. Though the idea of parsing data taken from his post, I wrote the workflow steps in little different way to not to use the loop action instead stick to for each action due to loop action being dependent on turning off safe looping setting which I personally dislike taking that setting off.



Repeating section rows will not come with row numbers, and also they can not be appeared in direct list columns because of the their one to many nature. Thus not allowing it for edit in excel mode.



The direction I am taking to address above is create a child list and main the repeating table data in the child list while storing their item IDs in the repeating table hidden rows for later use of update. while my project was pretty complex with bunch of look up fields and all data types like dates, numbers and persons, for the easier understanding of concept I created  a separate project and will make use of that here. 


We need two simple lists for implementing the solution. First list I am naming NintexPOC for keeping it simple with just 2 columns 1. Title  2.MyRepeatingData - mulitline text plain.

Second list I am naming as Expense Records with 4 simple columns such as 1. Title 2. Expense Date 3. Amount and 4. ParentItemID(this is a look up field from NintexPOC to maintain parent child relationship).


Part 1: Now let us start with key element of the solution, that is our form with repeating section. I placed the names of each control in the repeating section in red font on the screenshot for readability. Provide your repeating section a name and also connect it to the multi-line text field we created in the list. Inside repeating section also keep a control for storing child list item id and make it hidden if you don't wish to display it to the user.

Once you connect the repeating section to multi-line text field and publish, create your sample data to give a peak at how Nintex generating the XML  for us. when you save an item at least with one repeating section row filled with data this is how it is going to look like.

NintexPOC - All Items

<?xml version="1.0" encoding="utf-8"?><RepeaterData><Version /><Items><Item><EName type="System.String">User2</EName><ExpDate type="System.DateTime">7/3/2017</ExpDate><ExpAmount type="System.String">500</ExpAmount><ChildItemID type="System.String">10</ChildItemID></Item><Item><EName type="System.String">UserOne</EName><ExpDate type="System.DateTime">7/25/2017</ExpDate><ExpAmount type="System.String">100</ExpAmount><ChildItemID type="System.String">7</ChildItemID></Item></Items></RepeaterData>

Part 2: Now its time for us to switch to workflow part of our solution which is where the greater possibilities with Get XML action and collection objects unfold.

As a step 1 simply get your multi-line text field data into workflow variable and add regular expression action in the workflow right after that. Configure the Regular expression step like below

For the purpose of building for loop action we need one dummy text field, we will use this only for setting up in for loop action box and won't use any where. Also create a number field with name Index and set default value as 1 to start with. This index variable is the key in the next steps. inside for loop we will also be keep doing increment it by 1 in each iteration.


Inside for loop action, now add Query xml action and add output blocks like below until you get all your named controls to variables. 


we will check if child item id is blank, if not blank that means we have an existing item so can update instead of creating new. If child id doesn't exist then create new item and get the newly created item id and store it back in the xml field with Update XML action.


End of workflow update current item with updated XML back to our multi-line text field. Now that we have each repeating row assigned with its corresponding list item id, when the child list items change we can use item updated workflow and update that specific row in the repeating row. It is much simpler workflow without any loops and explaining it here would be too boring to read  . Attaching full solution for download including list templates and both workflows.

parent child forms listviewcontrol beginner



First of all, excuse my english, please.

I'm not an expert, but I would like to share with you my first significant development using Nintex Forms. It could be easy, but I'm very happy with it  


I have just developed a Parent / Child structure using List view control to show child list inside Parent Form. The idea is to have child data in a independent list in order to manage the elements properly.

I'm not satisfied with the repeating section to do it, because data is not easy to manage later, for example if you want to do tasks for each child element using workflow, or to make a report downloading the lists to Excel file and working with Power Pivot.


My targets are:

- To have the child data only in one place (not in XML in the parent list and the duplicate in a child list)

- To have the parent "primary key" in the child list to have the relationship in the reporting system (in my case Excel and Power Pivot functionality)

- To allow the update of the created child items when you want

- To use workflow to create / manage tasks using the child elements


The example:

In this case the parent child has data about process events in a Chemical Industry, and the child list has actions to do by the staff related with each event in the parent list.


The process:

Let me show my parent form. I use "tabs" to distribute and organize data using the wise advices learned in the forum 


The red mark shows the "primary key" of the parent element, generated using workflow when the element is created.


The tab "Acciones" has the list view control with the child items. You can see the primary key in the first column:

The list view control is filtered using a calculated control in the form, who stores the "primary key"

So, only the actions related with the parent item appears 



(Be careful here, you can filter and sort the list using the list headers. If you do it, filter values could be removed. I'll show you how to avoid it later on)


New child item

To create a mew child item, I have prepared a button on the top of the list.




The button is "save and send" type, and I use URL redirection property to point to the child form with the parent ID at the end of the URL string:




I'm not using the list "Add new item" link (by default it appears in the Sharepoint list) because I don't know how to pass the ID variable to it. In fact, I just remove the link to avoid troubles. I'll explain how to do it later on.


In the child form, I get the ID to update the key item. Let me show how:


I use a calculated control to geet the ID value from the URL string, using the following formula:




Buscar (in spanish here) is Lookup the parent  list "Incidentes_Operacion" to get the parent primary key "Num_Incidente"


fn-GetQueryString is the function to get the variable from the URL string (Thank you very much Marian Hatala )


Now, you connect the calculated control with the appropiate child column and the relationship is done 


Updating an existing child item

In case of you want to update an exisiting child item, yo don't need to pass the key, because the child item get it when it was created. So, you can use the update action from the child list menu in the list view control in the parent form:



Back to the parent form from the child form when you finish edition:

By default, when you save the child form, Sharepoint come back to the list. So you need some code to return to the parent form (and to the related parent item). I use the following strategy:


The button "GUARDAR" is save and continue button. The user click on it to save data. The button Volver is not a button, is a calculated field with an hyperlink (there are  examples in the community of how to do it):

The formula that I'm using to back to the parent form is:


"<a href=\" http://xxxxxxxxxxxxxxxxxx/Lists/Incidentes_Operacion/EditForm.aspx?ID="+CC_Parent_ID+" \">Volver</a>"


CC_Parent_ID  is the calculated field I use to get the parent ID from the parent list using lookup formula and using the child column with the "primary key" as an argument. So, using this link you navigate back to the parent form.


This method has to advantages:

- You came back to the parent form from both new item action or updating action 

- The parent form is UPDATED with the new data when opens 




Removing "add new item" funtonality in the chil list view and header filter / sort functionality:


As commented, you need to remove "add new item" and "header filter / sort" functionality from the child list into the parent form to avoid mistakes.


To do it, you must to edit the page when the parent form is alocated and include a web part selecting "Command sequence Editor" (I think is something like that, in spanish is "Editor de Secuencias de Comandos":


Then you must include the following code fragment:


The first fragment is to remove the add new link

The second one to remove header funtionality, in this case in the primary key column


Save the changes and the work is finished. 


Thank you for your attention. Any comment will be wellcome.





Posted by greenawayr Moderator Sep 29, 2017

So this morning I was trying to write to a date & time field on a button click on the new responsive forms designer. I clicked on the button settings > Advanced > Connected To but in my list of columns, my Date & Time column wasn't there. It appears that only the text based columns can be written to here. This was frustrating, especially as you can write the date and time to a text column using the common references.


Ah-ha, I wonder? Let's see.


That light bulb moment you just witnessed was me thinking, if I set the button to write to a Single Line of Text (SLOT) using the "Current Time" reference, I get myself a date and time, that's fine, but no good for reporting really, I want my datatype to be Date and time, not just a string containing the date and time. Nevertheless, I published the form and knowing that my button was configured how I wanted it to be, then in my list, head to the List Settings, head to the SLOT column settings for the column I've just connected my button to and in these settings I can switch the data type from SLOT to Date and Time. 


Now here comes the test, firstly, is my form still configured? Head back to the form designer and check my button settings, all the configs are still there...great.


Now create a new item in my list and hit that button and Bingo! Date and time written to a date and time column, even though the form designer didn't really want me to. Perfect.


I'm guessing that Nintex didn't want people to be able to write to date and time columns because they might be prone to putting something other than the date and time in here and values will be lost, but as they give us a reference, it still seems odd to me.


Anyway, this relatively simple fix means you can write to a datatype using certain actions that you might not have thought you could. 


I wonder whether the same might work with a Choice column (you could allow Fill In choices for flexibility perhaps)?


On that note, what other workarounds/fudges/obstruction breakers/loopholes have you discovered in your journeys through Nintex? Not after whizzy javascript solutions here, stuff that people can do from the interface with no custom code. Intrigued to find out what else lingers out there.

Nintex is becoming ubiquitous in the global IT landscape as adoption increases in their cloud offerings building on top of their highly successful on-premises solutions. Because of this, knowledge of good workflow design and development practices specific to Nintex is paramount.

Here below is a short list of key tips to help optimize performance and maintainability of your solutions. 

Tip #1 - Use Workflow Constants

One of the best features with Nintex on-premises is their ability to store credentials for a service account as a workflow constant. When a credential has been created, you can use those credentials without having to know the name and password of the account. The credentials are stored in the Nintex Workflow configuration database and are encrypted with DES encryption. Workflow constants can be created at the Site, Site Collection, or Farm level. You can see how it gets setup in the image below.

Workflow Constants diagram

To use a stored credential, simply click on the 'Select credentials' lock icon and select the credential constant from the lookup dialog box. More details can be found here.

Tip #2 - Processing and Load

A consideration that is often overlooked is the effect on performance of different actions within the workflow which can slow down its execution affecting performance. 'Execute SQL' or 'Query LDAP', for example, require more processing while 'Log to history list' and 'Build dynamic string' require much less. Nintex recommends breaking actions with a heavier load out to their own separate sub workflows.  

Any updates to the list, start/stop workflows, or update XML actions do not get processed immediately and are not necessarily executed in the order of the workflow. These actions will be batched up and executed according to what type of actions they are – Nintex or Microsoft. For example, this:

Workflow Execution Order pic 1

will actually execute as this:

Workflow Execution Order pic 2


This is happening due to the Nintex actions getting batched together and executing before the Microsoft "Update List Item" action. Another wrench in this puzzle is that although the Nintex batch may start first, it may not complete execution prior to the Microsoft action. You might think to put a 'Commit pending changes' action after the Microsoft action but that is still not a guarantee. The permissions action, for example, takes longer to complete and can possibly end after the 'Update List Item' action. It is better to use 'Pause for Duration' and set it to at least 30 seconds to make sure all the actions have completed before continuing. Alternatively, you can also use 'Wait for Field Change in Current Item' if that works for you. If you are on Office 365, Nintex for Office 365 does not have 'Commit pending changes' so you should replace it with a 'Pause for Duration' or 'Wait for Field Change in Current Item' action.

Tip #3 - Build Your Content

When designing your workflow, in O365 or on-premises, it is ideal to have a workflow that has the smallest number of actions. The benefits are in reduced server load, speed of execution, and reduced complexity. One of the recommended techniques used in developing workflows is building your content by adding relevant information to a variable as it becomes available.

For example, email body content often has to be formatted using basic HTML to display tables and other formatting. This can be built in a variable as the data is collected. Using a "Set Workflow Variable" action, you can set the variable to itself plus the additional formatting and data. So a var_EmailBody variable would have a value of "{Variable:var_EmailBody}<TR><TD>my new data</TD></TR>" when adding new data.

 The results of this method are very apparent. Workflows that previously looked like this:

Bloated workflow design

Can now start to resemble this:

Streamlined workflow design


Resulting in less actions, faster execution, and a better workflow overall.

Sometimes when you use an Action Set to execute and/or group some actions, it appears when part of the main flow.




It happens that when you have actions nested inside others, you'll have the possibility to mark them to run as the workflow owner only from the principal one.


Only actions at the root path of the workflow will have the Run as Workflow Owner option.  If you have an action in any branch, this option will not be available.

My last project required creation of a dynamic list of approvers for the approval process (a coincidence? ), based on a location and volume threshold. And some other parameters, but this is not a case. At first I naturally thought about a list, that would hold such mappings for me. Then I thought to query that list within a workflow, using filtering to gather only a specific subset and then, using a state machine, to go through and assign tasks.


But there was a catch! Customer expected, that the form should allow to display that list of dynamically gathered approvers and then to show how each one expressed approval. And with the possibility to add or remove existing ones!


Naturally, I decided to use the repeating section control, but I didn't know how to fill it dynamically. I managed to do that however, and the results look like this:

And the source list for data lookups:

How such dynamic repeating section can be made?

Step by step. Let's begin!


The data structure

  1. Locations (just a simple list with title)
  2. ApprovalThresholds - a list built of the following fields:
    1. TItle
    2. Approver (person field, many users allowed)
    3. Location (single lookup)
    4. Threshold (number)
    5. OrderNo (number, in my case it was used to identify a group to which specific user belongs)
  3. WorkingList (it was called differently, but for the demo let's stay with this name )
    1. Title
    2. Location (single lookup)
    3. Volume (number)
    4. Approvers (multiline text field, plain text)


The form

Then I created a form for the WorkingList list. With some enchantments of course:

  1. Volume field was given a JavaScript variable name: var_Volume;
  2. Location field was given a JavaScript variable name: var_Location;
  3. And then I deleted the default "Approvers" field, the textarea, and replaced it with a repeating section:

The repeating section has added a CSS class: approvers:

It is built of three input fields:

  1. Approver name - is given a CSS class: approversApprover
  2. Approver email - is given a CSS class: approversApproverEmail 
  3. Approval group - is given a CSS class: approversOrderNo 


There are also two checkboxes, one is having a JavaScript variable name: var_IsEditMode, the other var_IsNewMode, to pass information to the script how to behave, having set the "Default value" to "Expression":


And basically that's it for the form. All the magic is habdled by a jQuery script.


The script

Script is doing the following things:

  1. It binds change and blur listeners to the Volume and Location fields;
  2. It defines function that is triggered by the listeners events;
  3. It adds dynamic controls to the repeating section once it is in the edit mode.
  4. It also allows to hide or leave untouched controls for the repeating section (hideNativeRepeatingSectionControlls variable)


AD. 1 - listeners and bindings

var clientContext = new SP.ClientContext();
var siteurl = _spPageContextInfo.webAbsoluteUrl;
var hideNativeRepeatingSectionControlls = 0;

NWF$(document).ready(function () {

    //hide "add row" link in repeating section
    if (hideNativeRepeatingSectionControlls) NWF$(".approvers").find('.nf-repeater-addrow').css("visibility", "hidden");

    //trigger if location, CapitalExp or Volume is changed - recalculate list of Approvers
    NWF$("#" + var_Location).change(function () { retrieveApprovers(); });
    NWF$("#" + var_Volume).blur(function () { retrieveApprovers(); });

    if (NWF$("#" + var_IsEditMode).prop("checked")) redrawRepeatingTableEditMode();


AD. 2- function handling the changes

function retrieveApprovers() {

    var oList = clientContext.get_web().get_lists().getByTitle('ApprovalThresholds');

    var camlQuery = new SP.CamlQuery();
    var locationArr = NWF$("#" + var_Location).val().split(";#");
    var location = locationArr[1];
    var locationCaml = '<Eq><FieldRef Name="Location" /><Value Type="LookupMulti">' + location + '</Value></Eq>';
    var volume = NWF$("#" + var_Volume).val().replace(/[\,]/gi, "");

    if (!volume) volume= 0;

    camlQuery.set_viewXml('<View><Query><Where><And>' + locationCaml +
        '<Leq><FieldRef Name="Threshold" /><Value Type="Number">' + volume+ '</Value></Leq>' +
        '</And></Where>' +
        '<OrderBy><FieldRef Name="Title"/><FieldRef Name="GroupOrderNo"/></OrderBy></Query></View>');
    this.collListItem = oList.getItems(camlQuery);


        Function.createDelegate(this, this.onQuerySucceeded),
        Function.createDelegate(this, this.onQueryFailed)


What id does, is gathering information from the form and construction of a CALM query, that it sends to SharePoint to get a list of approvers. If it succeeds it triggers the "onQuerySucceeded" function.


What that function does is making a loop through each returned row.

Then, for each approver (as there may be more than one) it calls SharePoint endpoint for additional information (like login or email):


function onQuerySucceeded(sender, args) {
    // Redraw the existing table, remove everything what exists, leave fresh instance

    var listItemEnumerator = collListItem.getEnumerator();

    while (listItemEnumerator.moveNext()) {
        var oListItem = listItemEnumerator.get_current();

        var approvers = oListItem.get_item('Approvers');
        var approvalOrder = oListItem.get_item('GroupOrderNo');

        NWF$(approvers).each(function (idx, obj) {
            var person = JSON.stringify(obj);
            person = JSON.parse(person);
            // get user's display name and ID
            var approverId = person.$1T_1;
            var approverName = person.$4K_1;
            var userData = "";

            // ask for users additional data
                url: siteurl + "/_api/web/getuserbyid(" + approverId + ")",
                method: "GET",
                async: false,
                headers: { "Accept": "application/json; odata=verbose" },
                error: function (data) {
                    console.log("Error: " + data);

Once it gets it (done) it pushes the information to the last, found row (.nf-repeater-row:last) using the '.approvers' class as the selector for the repeating field control.

This is a key point here. The class name is the only way for the script to reach the control and then its contents.

If the "hideNativeRepeatingSectionControlls" is set to true, it also removes the "X" icon from the row, so that it cannot be deleted using the UI. It also covers it with the overlay, so the user won't be able to change the values.

You cannot set fields to be disabled or hidden using the CSS or Forms rules, as the hidden or disabled fields, for some reason, are not being taken into consideration during the form saving. So if you put a value into such field, that value won't get saved to SharePoint.

Instead use "visibility:hidden" (rather than "display:none") and a calculated field or overlay to make a field "disabled".

After it fills all the field in a row it simulates the "click" on the "add row" link that is underneath the repeating section, to create a new, blank row:

    }).done(function (userData) {
                NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo input').val(approvalOrder);
                NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo').attr("style", NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo').attr("style") + "background-color: transparent !important;");
                NWF$(".approvers .nf-repeater-row:last").find('.approversApproverEmail input').val(userData.d.Email);
                NWF$(".approvers .nf-repeater-row:last").find('.approversApprover input').val(approverName);
                // remove image for row deletion
                if (hideNativeRepeatingSectionControlls) NWF$(".approvers .nf-repeater-row:last").find('.nf-repeater-deleterow-image').css("visibility", "hidden");

                // append overlay to avoid editting ;) fields must be enabled to allow proper save
                if (hideNativeRepeatingSectionControlls) NWF$(".approvers .nf-repeater-row:last").append('<div class="approverOverlay"></div>');

                //add next row

Then it removes the last, empty row, as it will always be added. It also adds, to every row generated by the process an additional class "toRemoveOnReload" so that the "redrawRepeatingTable()" function will know, what should be deleted, once the repeating section requires to be re-created.

    // remove last, empty row, as it is always empty
    NWF$(".approvers .nf-repeater-row:last").find('.nf-repeater-deleterow-image').click();

    // mark all additional rows as to be removed once control requires redraw:
    var addedRowsSuffixes = NWF$("input[name$='InternalRepeaterAddedRowSuffixes']").val().split(",");
    NWF$(addedRowsSuffixes).each(function (key, val) {
        NWF$("div[name='" + val + "undefined'").addClass("toRemoveOnReload");

    return true;

The redrawRepeatingTable() function looks like this:

//function used to delete existing rows in repeating table leaving it as new
function redrawRepeatingTable() {
    //delete all existing repeating table rows, then build them again
    NWF$(".approvers .toRemoveOnReload").each(function () {

    NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo input').val("").css("background-color", "rgb(248, 248, 248) !important");
    NWF$(".approvers .nf-repeater-row:last").find('.approversApprover input').val("");
    NWF$(".approvers .nf-repeater-row:last").find('.approversApproverEmail input').val("");

The last function, that is called redrawRepeatingTableEditMode() is used to inject suffixes and the "toRemoveOnReload" classes to the loaded repeating section control, generated when form is displayed in edit mode:

//function used to enchance table of approvers created in the edit mode:
function redrawRepeatingTableEditMode() {
    var suffix = 1;
    var suffixes = "";
    NWF$(".approvers .nf-repeater-row").each(function () {
        NWF$(this).find('.nf-repeater-deleterow-image').css("visibility", "hidden");
        // inject prefix into div's ID'
        if (suffix > 1) {
            NWF$(this).attr("id", suffix + "_" + NWF$(this).attr("id"));
            NWF$(this).attr("name", suffix + "_undefined");
            suffixes += suffix + "_,";

        //increment prefix value
        suffix += 1;

    // inject suffixes into the dedicated field
    NWF$(".approvers").find('.nf-repeater-addeddrow-suffixes').val(suffixes.substr(0, suffixes.length - 1));
    var addedRowsSuffixes = suffixes.split(",");
    NWF$(addedRowsSuffixes).each(function (key, val) {
        NWF$("div[name='" + val + "undefined'").addClass("toRemoveOnReload");

Note that the Repeating Section is holding "suffixes" of each added row in a hidden field named  "InternalRepeaterAddedRowSuffixes". The string is built using the pattern: #_;#_;#_ where # is next number, counting from 1. You can also note, that each row in repeating section has a name, starting from the suffix and "undefined" token. That is another way you can iterate them


This way of building dynamic repeating sections doesn't need only to be used for gathering approvers. You can use it to get any kind of dynamic sets, like products, parts (depending on a chosen product) etc... I see a lot of possible use cases


I have attached my exported form and the JavaScript to the post. Enjoy!


Print friendly Nintex Forms

Posted by cazza162 Moderator Sep 11, 2017

Without having Nintex Forms Enterprise and the handy "Print to PDF" functionality, we often spend a lot of time on workarounds for this.  My good friend and colleague Gary Powell-Jones came up with this solution that he has allowed me to share with you all:

Print friendly Nintex Forms

Designing the form

The form can be designed to allow items to not be printed (e.g. appear only on screen) or appear only when printed (such as a disclaimer).

For print only items, add a css class of printonly to the control or element

For no print items, add a css class of noprint to the control or element

Note that the JavaScript below will work even if there are no controls or elements with these css classes

Form custom JavaScript

Include the following snippet in the form custom Javascript. It adds a function called ‘PrintFormHtml’ to print the form, a function to hide print only elements when the form is initially loaded.


function PrintFormHtml(){








 return true;



NWF.FormFiller.Events.RegisterAfterReady(function () {

  NWF$(document).ready(function () {

   NWF$('.printonly').css('display','none'); //THIS HIDES PRINT ONLY ELEMENTS



Print Button

Add a button to the form, using the JavaScript action. The action will be PrintFormHtml();. Optionally, the button can be made visible on the SharePoint ribbon using the standard Nintex settings


When the button is clicked it

  • hides the suitebar
  • hides items with the CSS class of ‘noprint’
  • shows items with the CSS class of ‘printonly’
  • calls the printer dialog


After printing, it resets the form:

  • showing the suite bar
  • hiding the print only elements
  • showing the no print items

Hi all,


during last years, several times I've encountered projects when the best suitable action in order to ask a user to do something in a workflow was a Flexi task action with just one outcome..


If the customer is using also Nintex Forms and because Outcome is a mandatory field, their following question is always: "Is it possible to autoselect the only option?" and "Is it possible to make it hidden?"


Until the use of the new Responsive Designer (at this moment available only for Nintex for O365), the only option in order to achieve this is the use of javascript, and I want to share with you how I do this:

  1. Add a class to the decision field (in my case "decision")
  2. Go to Form Settings and in Advanced Javascript put the following script:

NWF$('.decision input').attr('checked','checked');
//NWF$('.decision').hide(); //remove comments if you want to hide the control

With the above script, the option inside the element with "decision" class will be selected, in case you want also to hide it, you can remove the comment on last line so it will be hidden from this case you can also remove the corresponding label and panel (think about the Delegation link) in order to reduce the space of the form, just move the control somewhere in the form, also overlapping some other fixed control (e.g over the logo), just to keep it in the form but without occupying additional space.


Hope this post may help someone and make him/her save some time..



Welcome to our monthly mention of noteworthy community contributors!


In May, we started a new way of highlighting people you should probably be following in the community.  It's a great way to really get a sense of their contributions.


Each month, I name 10 people to the Honor Roll, and ask you to visit their profile and then "follow" them to spark connections.  This month, I wanted to point out that we have a mix of community members and some Nintex Technical Evangelists!


Richard Ruth is a SharePoint developer who's created some great blogs recently. And Eric Rhodes is a long-time member who regularly shares his knowledge here and in attending our annual conference. Mike Oryszak is a senior solutions architect who freely offers good advice in a friendly manner. I love his helpfulness. And Paul Crawford is a freelance SharePoint consultant and Blue Ribbon Group member in the community who is always willing to get his hands dirty to help someone.


William Knowles, Jaimé Seita, Terry Simpson and Gonzalo Marcos are Nintex Technical Evangelists whose writing you are going to see a lot more of in the community. If you like knowing the minute someone posts useful info, follow them!


Here's how: Visit each of their profiles and click "follow," which is just to the right of their smiling profile photo.  Here's an example:



Why do this?  Because following someone puts their community activity in the news stream of your choosing and exposes you to what they're doing in the community.


This month's Honor Roll members:

honorrollHonor Roll

Mike Oryszak 

Paul Crawford

Lachlan Ainley (Hawkeye Product Marketing Mgr)

William Knowles (TE)

Jaimé Seita (TE)

Eric Rhodes

Richard Ruth

Matt Jennings (Forms and Mobile Product Marketing Mgr)

Terry Simpson (TE)

Gonzalo Marcos (TE)



honor roll big



Honor Roll members will get this badge in their reputation center, along with 100 points.


If you'd like to nominate someone for the honor roll next month, post their name below and tell us why you think they should have a bigger following!

I have been working with Nintex workflows for a long time now and have only just started using this action.  It is so simple but so powerful and has saved me doing this painful step in a lot of my workflows:



I have a workflow that runs for all types of users entered into a list.  Most of the workflow is relevant to all types of users but there are some things that I would like to be done only if the user type is Employee.  Yes, I could use a Run If action, but I am using this fairly simple scenario to explain the filter action.


The Filter Action

As opposed to a Set a condition action where only one branch is executed, or a Run if action where the contents are run only on a condition being met, this action literally only executes the actions below it if the condition is met, otherwise the workflow is ended.  No need to add actions to a Run if container, or to add actions to one branch in a Set a condition action and an "End workflow" action in the other!

Action Configuration

Very similar to the Set a condition and Run if actions, you can specify:

  • Condition:  what you are comparing (i.e. current item, variable, metadata etc)
  • Comparison:  equals, not equals, contains, greater than etc.
  • AND/OR conditions

For my specific example I have the configuration as follows:


I have designed a lot of my previous workflows using the very first image on this post but will have to keep the filter action in mind going forwards as it does the same thing and is often overlooked!

Each month, I like to highlight valuable community members and name them to a monthly honor roll.  You, dear community member, are asked merely to follow them.



Just hover over their names and click "follow" or visit their profiles and follow them there to get their activity in your newstream in the community.  This helps expose you to how active community members are engaging with other Nintex users.  You'll see what content they're creating, and responding to.  It's a great way to enrich your community experience.


This month, we have a nice mix of customers, partners and employees.  I want to especially call out Bashya Rajan,  nmarples ,  Lakshmi C, and Philipp Lucas, four Nintex customers who always offer friendly, useful advice that is coupled with gentle suggestions about how to look at solutions from a different perspective. Gentlemen, I appreciate your approach and the help you've given others in this community. Thank you!


Our Nintex Partners are a tremendous asset to this community, too. The smartest ones know that sharing their knowledge (as they frequently do with informative blogs) helps raise their profile in the workflow world.  Ben Stori, Patrick Abel, thanks so much for your help!


Nintex Technical Evangelists round out the list. Be SURE to follow them to get notified when they post, so you don't miss their insights and news!


This month's Honor Roll members to follow:


Congratulations and thank you to all of this month's Honor Roll members!



honor roll big


Honor Roll members will get this badge in their reputation center, along with 100 points.


This is not just open to the whims of the community manager! If you'd like to nominate someone for the honor roll next month, send me a message: or ping me via the community!

What steps can be taken to improve accessible experience on Nintex Forms?


An example of making Nintex Forms elements focus-able with tab-index and JavaScript?


    Manage focus on a form using keyboard commands or key handlers?


    How can we add WAI-ARIA authoring practices (roles or states) to Nintex Forms HTML markup for screen readers?


    Best practices to manage keyboard focus when using dialog boxes within Nintex Forms?


    Horizontal fields vs. Vertical fields how will tab order behave?

    • The form CSS / JS are highly customize-able, depending on what the accessibility standards are requiring for this question, they should be able to update and modify accordingly.


    Repeating section how will tab order behave?

    • All controls should function the same with tabbing behavior.  After doing some testing, it doesn’t look like the ‘Add New Row’ is part of the tab index.  This would likely require adding a JavaScript button to click the ‘Add New Row ‘ button.


    How will all the controls like check boxes, radio buttons, and other controls behave?

    • These can be edited by tabbing through the choices.  You can select the option by hitting the space bar.

    Overall Compatibility with Jaws reader

    • Haven’t tested with that one in particular, but you can use explicit labels to provide the functionality needed for other screen readers.
    • Added Value of Label Associations

    Filter Blog

    By date: By tag: