Use Case: Go Back or Skip Stages Using Branch By Stage in Nintex Workflow Cloud

There are plenty of reasons why we would want to skip branches or even go back to a previous one in a Branch By Stage action within Nintex Workflow Cloud. Everything from approvals that need to go directly to an executive to scenarios where more data is required in order to move forward. What ever the reason, moving to the desired stage is easy to setup and can be done a variety of ways. This use case will walkthrough how to do so leveraging task forms and simple logic gates. Let’s dive in!


For this one, we are going to look at a multi-level risk review process. This process has 4 different levels, but there are some business rules in place that will determine where and when to move to next. Risks can be Low, Med, High, or Critical, and follow a designated review path depending which level is selected. Here is a breakdown:

  • Level 1 – Review Risks: Low
  • Level 2 – Review Risks: Low – Medium
  • Level 3 – Review Risks: Medium – High
  • Level 4 – Review Risks: High – Critical

This means, for example, that a risk review that has been submitted as “High” skips to Level 3 automatically and then moves to Level 4. You’ll notice that each risk level requires at least 2 levels of review, this is by design. Another business rule that needs to be considered is that any review level has the ability to send it back to a previous level for reevaluation. Let’s take a look at how we can accomplish something like this above scenario using Nintex Workflow Cloud.


The Workflow

For this, I built out the full 4 level approval workflow, but I want to focus on the Low and Medium levels since we can extrapolate how to build the other branches from these. The form could be anything, but for the sake of our use case, there is a dropdown control that determines the “Risk Level” and we use that to drive where to start in our Branch by stage action.

If the form control evaluates as “Low”, it will start here, otherwise it will go to the proper branch. Starting off with the “Low” branch, we see that it is a simple task for someone to review. Here, there are only 2 outcomes that could happen; they Reject it and cancel the process, or they Approve it and moves onto the next branch, “Medium” in this case. Keep in mind that all reviews are 2 levels. Here is how we can achieve this within the workflow.

This is the most simple way to approach multi-stage approvals. Let’s add in some complexity such as what if the “Risk Level” starts at Medium or we need to provide a way for reviewers to send something back for more information. With these in mind, we can take a look at the “Medium” branch in our workflow.

Here we see the basics of the “Medium” risk level task are similar to the “Low” branch but with the additional outcome on the task for “Need More Info”. This allows for reviewers to select an outcome that does not move it forward to the next step nor cancel the process entirely.

You also might be noticing that we are using a “Branch by condition” here as well. This is because now that we are deeper into the process, we need to evaluate what the “Risk Level” is in order to decide where to do to next. In the scenario that the risk is “Low”, this review step is the second review and the process is completed, but if it is “Medium”, the process starts here and moves onto the proceeding branch (“High” in this case).


The same logic and approach can be used when building out the “Need More Info” branch. If the “Risk Level” is “Low” then we can move back to the “Low” branch in the workflow, however, if it is “Medium”, we simply move back to the “Medium” branch effectively re-issuing the task.

Looking back at our risk levels, we see that “Medium” starts at level 2, so how can we start the workflow in the proper branch? If you look at the “Branch by stage” action and how we configured it, we specify the “Initial Stage” by using the “Risk Level” control from our form. This means that whatever the control value is will determine what branch to go down first.


Taking it to the next level

For bonus points, I wanted to see how we could ensure that each review was 2 levels, even in the “Critical” branch. The way I approached this was to nest another task within the “Approve” branch and only go down that path if the “Risk Level” is “Critical”. Since this would be the second level review already for “High” level risks, we can simply exit the branch and move on with the rest of the workflow as needed.

Final Thoughts

There are many different ways to approach this problem within a workflow, but leveraging a State Machine, Branch by stage action in Nintex Workflow Cloud, helps make it easy to build a solution around and easy to understand. You’ll notice that each branch in the action has a “Change stage” action and this is for good reason. Each branch is really just a loop and the “Change stage” action tells the loop where to go to next when it gets to the end. Without that action, you could imagine, the branch would continue to loop!

How are you using the Branch by stage action? Are there other ways that you would have solved this business process?

There & Back Again: Google to Microsoft with Nintex Workflow Cloud

When it comes to Nintex workflow, many times the first thought is “Microsoft”. And while this is certainly still common, there has always been the ability to go a different direction when leveraging the power of the Nintex platform, especially Nintex Workflow Cloud. Within Nintex Workflow Cloud there are a multitude of connectors ranging from AccuWeather to Zendesk and an Xtensions framework that allows users to create their own workflow actions. This paves the way for processes to be built and optimized for with the current systems in mind without the need for complex workarounds or changing the process to fit the tool. For myself, a lot of times I simply frame this as the ability to change platforms or systems without having to rebuild the entire process. Let’s explore this idea more, but specifically around Google and Microsoft.

The Story Thus Far

I recently worked with an organization (Company A) that was going through some growth via acquisitions and had to consolidate systems, platforms, people, and processes. In the middle of all of this, Nintex Workflow Cloud was the way that the majority of their processes were being automated and how data was getting to the correct people and systems. Things like on-boarding new employees (which they would be using a lot of given the acquisition), contract and content management, and other various back-office processes connecting to legacy applications. These processes leveraged a variety of platforms but many times Microsoft was at the center of it. Whether it was SharePoint Online, Excel, Word, OneDrive, or even just posting content to Teams, Microsoft products were used to facilitate processes a lot. On the other hand, the acquired organization (we’ll call them Company G), used the G-Suite. This was how many things were advanced through their processes without the luxury of Nintex Workflow Cloud. The immediate response was to migrate all the new content and process from Google into Microsoft since there was already more being done with Microsoft within Company A; but was this the right approach? How much re-work was required taking this approach? These were the questions they needed to stop and evaluate before making decisions. This is where a simple approach changed all future decisions.

When Company A began to evaluate and catalog the processes that they were acquiring, they quickly realized that many of them were quite similar. Capturing data via forms and then pushing that data into the proper systems for retention. The key differences were where the data resided and the complexity of the tools that orchestrated the automation. Many times, they found that once the data moved to the new system in the process, that system would be leveraged to continue the flow of work. Things like notifications and tasks were commonplace, but each different depending on the system that it came from. This led to confusion for employees as they did not know where to go to complete their work. External participants faced similar issues; the notifications they were provided to complete essential steps in their processes were not standardized or streamlined.


With the power of Nintex Workflow Cloud, the Company quickly saw the potential to consolidate processes all under one workflow platform but still allow for the data to flow to the proper systems. This was as simple as adding a connection within Nintex Workflow Cloud and then adding the necessary actions in the right place. An example of this was when their templates had to be used for Document Generation, depending on where the template resided, it could be pulled in and used in the workflow.

In the above screenshot, we see how easy it is to add two actions to replicate what is already being done but pointing to where the content already is. In this case, the is a need to grab logo images and the document template to be used in the document generation action. Another example of this that came up was having the notification come from different systems. In this case, there was a need to have meetings set using Google Calendar or Microsoft Exchange depending on the business needs. Using a simple branch action within Nintex Workflow Cloud, we can easily achieve something like this:


Final Thoughts

When it comes to consolidating automation, there is a lot of consider and ultimately ensuring that the processes continue to run is paramount to all else. This means that while some parts need to be re-architected, merged into another processes, or down-right deprecated, the first concern should always be continuing execution of the processes. With Nintex Workflow Cloud, we can easily achieve this by dragging actions around to rearrange the flow of the process. We can also add in a multitude of different connectors so that the data gets to (or is pulled from) the proper system. We remove the system dependency and open a world of opportunity when it comes to process automation.

Use Case: Extract Excel Data in Nintex Workflow Cloud

I had a specific use case come up with a prospect recently around pulling data from an Excel workbook. The data needed to be validated against the data that they had in their records. Using Nintex Workflow Cloud, we were able to upload an Excel file into OneDrive and then pull data from that file to validate. I won’t go into detail on how things were validated but want to share how we can pull the data from Excel and use it within a workflow as well as how to find the Excel file in OneDrive.

Getting Started

Keeping things simple, we will begin with the form. The main control that is needed is the File Upload. This will allow for the Excel file to be uploaded and then passed to OneDrive. When configuring the File Upload control, you may want to consider limiting the number of files to be uploaded and even the extension to only allow .xlsx files. This will ensure that only one file will be uploaded, and it will be an Excel file.

Alternatively, you could leverage an Excel file that already exists within OneDrive and not worry about uploading a file. If you want to go in this direction, you can skip over the next parts and move right to the Get Table Data section and see how to pull data from an Excel file.


The Workflow

Now that we have the form sorted out, we can move on to uploading the Excel file to OneDrive so that we can extract the required data from it. This is super straightforward and only requires one action, “Store a file”. In order to use the Excel actions within Nintex Workflow Cloud, the Excel file must be stored in OneDrive. We do have actions for pulling data from Google Sheets, but perhaps we will cover that in another post.

With the Excel file uploaded and now sitting in OneDrive, we can extract the required data from it. In order to do this, we need a few things; the file name, and a way to search our OneDrive for that file. First, let’s get the file name. This can be pulled from the File Upload collection variable within the workflow. The File Upload variable is a collection because it could contain multiple files, but if following along in this scenario, there will only be one file, so we can pull the data from the collection where the index is “0”. Once we have the data, we simply query the JSON looking for “$.blob.fileName”. Here is an example of the raw data along with the parsed result:

File Upload: [“{\”blob\”:{\”name\”:\”999a9999-aaaa-999a-a999-aaa999999999/aa99a9a9-9a99-999a-999a-9aa99a99a99a_9_9/999999aa-99a9-9aa9-99a9-9a9aa9a9a99a\”,\”fileName\”:\”AnotherExcelFile.xlsx\”}}”]
Parsed File Name: AnotherExcelFile.xlsx

Next, we will need a way to get the workbook ID. Since we are using the form and workflow to upload the file, we cannot select it from the dropdown menu in the Excel action. So how do we get the Workbook ID? Well, honestly, there is not an easy way within Nintex Workflow Cloud other than to go through the GraphAPI…which is exactly what we do! However, rather than writing that call, why not use an Xtension within Nintex Workflow Cloud?! Below is a download of the .json xtension file along with the instructions on how to set it up in your environment.

With the file name ready to go, we can use it to find the workbook ID using the xtension we just added. The xtension is expecting a file name (this is what will be used to find the file) and then return a collection of results. It returns a collection because there may be similarly named files it the result could return more than one file. Due to this, we will then need to loop through the collection to match on the file name exactly.


I built out the xtension this way to allow for other use cases than just this one I am building out. There may be a need to find multiple Excel files that all have “customer” in them or possibly different versions. The xtension is flexible to accommodate different scenarios and can be adjusted to return more data if required. For now, I am simply returning 2 data points: file name & ID.

The Get File Metadata action above is the xtension followed by the loop actions to get through the resulting collection. Within the loop, if we find a match to the file name that was uploaded, we store the workbook ID. For this scenario we know that the returning collection only has one file, but you may have more and may have to adjust the logic here based on your business needs. Ultimately, we need the workbook ID for the Excel file you wish to pull data from. Once we have that, we can move on to the next step of pull data out of the file.

The Excel File

This is honestly the easier part of this scenario because there are already Excel actions within Nintex Workflow Cloud. All that is required is to configure the actions and then do something with the data. Let’s start with getting the data. We can either get data from the Excel file by either columns or rows. Both will return data from the file but deciding which to use is dependent on how you want the data returned; all of the data per row or all of the data per column. In this scenario, I only want to pull out the first two (2) rows of data and only the first two (2) columns is required. I prefer to get the row data because the data is setup so that each row is a full set of customer data. If the data was setup to associated all in one column, using the Get table columns action would be a better approach.

When getting data from Excel it returns an object. Within the object there will be collection of rows and within that, an index (row number) and a collection of the row data. The row data is what we need. Understanding how the data is organized will help us when building out the workflow. Below is an example on how I approached it.

  • Loop through the collection of rows
  • Loop through the row data collection
  • Get data from row data collection for each column needed (in my scenario, I only need the first two columns for first and last name)

Now that we have the data, we can send it off to compare against other systems of record, upload to a SQL table, or anything else within the workflow.

Final Thoughts

This was an interesting use case because of the need to upload a file and then query that file for the data within it. This pushed us to build out an xtension to get the workbook ID from OneDrive. While the above scenario was simple, it proves out that we can easily get the data from the Excel file and continue to do the rest of the process as designed. I would also encourage users to evaluate both ways of getting data from Excel; row data vs. columns data. Using the column data action returns the data slightly differently since it does return the column name that was used in the table. This is extremely useful if you do not know what the data is and need to out context around the process.

How To: Add Repeating Section Data to a Task Form in NWC

I talk a lot about repeating sections here, and for good reason. They allow us to collect repeating data in a clean format without having to add a static number of controls. In the past I have provided examples on repeating section in DocGen, O365, and some on-prem solutions using repeating sections. In this blog, I wanted to cover how we can take repeating section data from our Start Event Form in Nintex Workflow Cloud (NWC) and present it in a task form for someone to review.

Use Case

The use case for this is straightforward enough, but to put it into context, we are going to create a form to collect repeating data and then route that data to someone for review. In the past, we would have broken out each line item in the repeating section as their own review step, but this time I want to review it as a whole. Currently within Nintex Workflow Cloud, there is no way to simply push the repeating section data that is in the start form directly to a task form repeating section control. However, we can present the data in a clean table format on the task form or even in an email.

Start Form

For this start form I just built out a simple with just a repeating section because I want to focus on this functionality within the workflow. You could easily add in other controls if needed, but for now, let’s keep it simple.

I added to the repeating section three controls, first and last name as well as email address. If you are adding other controls, you may need to parse the data further to get just a simple text string to make things clean. Once you have your form built, we can move on to building out the workflow.



In the workflow, any number of things could be going on, but in order to get the repeating section data from the start form and into a task form, we are going to build out three parts to piece it all together. In order to put this all together, we are going back to good ‘ol HTML. If you need a refresher, check out for some basics. I broke this out into three parts to help validate the data and to easily make changes later on. Here is how I approached it:

  • Create a text string – Create the Table CSS
  • Create a text string – Create table row (this will be inside a loop for each row)
  • Create a text string – Create full table

First up we are going to make the table look like a table and not just a data dump. You do not have to add this, but it does make it look much cleaner. Feel free to create your own or go off of what I have below for the first step.

<!DOCTYPE html>
table {
  font-family: arial, sans-serif;
  border-collapse: collapse;
  width: 100%;

td, th {
  border: 1px solid #dddddd;
  text-align: left;
  padding: 8px;

tr:nth-child(even) {
  background-color: #dddddd;

Once all of the CSS is finalized, be sure to store it to a variable, something like table_css.

Next up, we need to loop through each row in the repeating section and pull out all the necessary data to build out each table row. For this we will need a Loop for each action and within the loop we will build out our row to be used within the HTML table.

<td>​‍[[First Name‍]]</td>
<td>​‍[[Last Name‍​]]</td>

Note that in the above section, table_rows, [[First Name]], [[Last Name]], and [[Email]] are all variables that are being inserted. [[First Name]], [[Last Name]], and [[Email]] are all variables that are being pulled from the repeating section within the loop action, and table_rows is the workflow variable this block is being stored to. We add it to the top of this text string so that every time we loop through and add another row, it text is appended to the end and then stored back to the variable.


Lastly, we need to put it all together to make an actual table to be used on a form or an email. To do this, we create one variable that has all of the pieces that we have put together thus far along with the necessary table headings for each column. For my example, I have “First Name”, “Last Name”, and “Email Address”. Note that table_css and table_rows are both of the variables that were created before. Here it is all put together and saved into a variable simply called table:

<th>First Name</th>
<th>Last Name</th>
<th>Email Address</th>

Task Form

Now that we have a variable that has the formatted table data in it, we can use it to populate a task form or even sent it in an email notification. In order to add this to a task form, simply add a label control to the task form and insert the workflow variable (table in my scenario).

When the form is created for the user to review the task, the data will render in the table format rather than just raw text. This can also be done on the task notification (or any email) by simply adding the variable to the body.


End Result

Start Form

Task Notification

Task Form

Final Thoughts

This is a great workaround for those looking to get the repeating section data out of the start form and presented in a clean, formatted way for end users. While this still does not allow for users to edit existing data that was already submitted, it does give them a chance to potentially catch errors and adjust where needed. Repeating sections within Nintex Workflow Cloud forms will continue to be worked on and features will be added, but until then, let me know what else you would like to do in the comments below.

How To: Dynamically Add AssureSign JotBlocks

There are a variety of ways to kick off the signing ceremony when using Nintex AssureSign, but if you are leveraging Nintex Document Generation, you may want to dynamically place JotBlocks before sending the document out. Here we will look at how to add in a simple signature and explore how we can add in other options.


Before we get too deep, it is important to understand what a JotBlock is when it comes to AssureSign. JotBlocks are how end users interact with a document that has been sent to them via AssureSign. Whether it requires a signature, initials, or some text, JotBlocks can be defined within the AssureSign portal on a template, or dynamically embedding them on the document. For this scenario, we are going to embed a signature JotBlock on a document. We can place the signature where we want but also leverage Nintex Document Generation to create a dynamic document rather than a static template.

Setting Up AssureSign

In order to get the signature when the document is passed to AssureSign, we will need to ensure that the JotBlock is setup. We can do this a few ways; create a static template to reuse over and over again, create a blank template with all of the required JotBlocks, or we can add an entirely new JotBlock in the document before sending it to the blank template. Creating a static template can be beneficial for those instances where the document that requires signature or interaction from the end user does not change but falls short when we are creating documents on the fly and the length and structure of the document can change every time.


In order to do this dynamically, we need to create a blank template. From here we can either add all of the required JotBlocks and embed tags in the document to override the location of the JotBlock, or create the JotBlocks in the document during the generation. Creating a blank template with every JotBlock is simple and easy, but may become an issue if there are constant adjustments that need to be made. Knowing how to dynamically create a JotBlock tag and embed it in the document makes the process as flexible as your process needs it to be. For this scenario, I will use a template that has a single signature JotBlock already on it, but will also create a JotBlock in the document for the user’s initials.

Note the name of the JotBlock (“Employee Signature”) as that will help us when we create the embedded tag.


Setting up the Document

In order to get the signature JotBlock to show on our document, where we want it, we will need to create an embedded text tag. If we are overriding the location of the JotBlock (as we are in this scenario), the name of the JotBlock is all we need since all other properties are defined within the AssureSign template. The tag itself can be setup as follows:


{{!##{Name:"Employee Signature"}##!}}

Yes, it is that easy!

Now we want to add another JotBlock for the end user to sign their initials under the signature. For this, we will need to dynamically create the JotBlock in the document. Here is the breakdown for all of the properties we want in order to create it:

Instructions:"Please use the mouse to write your initials.",

Based on the above, we see that we are creating a JotBlock for “Initials” name “EmployeeInitials”, and it will be “Written” in “Black” ink. Since the document will be generated and then sent to AssureSign, we can start to do some dynamic things with this, like passing the email address from Nintex Document Generation. Here is what the Word template looks like for our workflow:


Putting it into motion

Now that everything is setup, let’s give it a go and see what the end user experience is like. In our scenario, we are creating an offer letter for a potential new employee, and they will need to sign and return the document. I am going to skip over the majority of the workflow and jump right into the signing ceremony. Below is the signature and initials capture along with where it is placed on the final document.

Final Thoughts

Adding embedded text tags allows you to override the location of a JotBlock that is already setup on a template. This gives you control over where the end user is placing their signature or where you need them to interact with the document. Going further and dynamically creating a JotBlock text tag within a document allows you to not only place the JotBlock where you wish but set properties without having to predefine them on a template. For additional examples and details around Embedded Text Tags, check out our post in the Nintex Community.

Nintex Acquisitions & What It Means For The End User

With everything that has been happening over the last few years, it is easy to miss a thing or two when it comes to Nintex and the capabilities we offer. Even for myself, it has been a roller coaster of new and exciting toys to build with. From acquiring K2 to the recent announcement around Kryon Systems, it is easy to lose track of what Nintex can do; we are not just a forms and workflow provider in the SharePoint space! For me, as a Solutions Engineer, I am always trying to figure out ways to solve business problems with automation tools, and Nintex keeps making it easier with every acquisition. But what does this mean for you, the end user? What does this new acquisition offer that is important, and better yet, why should you care? I wanted to take a quick minute and dive into those questions and talk about where we go from here.

What does this acquisition mean for me, an existing customer?

In a word, more. More of what Nintex already focuses on, process management and process automation. With the acquisition of Kryon, we add to our offering the power of process discovery along with a Top 5 leader in the RPA space. Combine this with what we already offer to help map, manage, and maintain processes, we end up with an even more robust platform that covers discoverability of processes that have yet to be uncovered automatically.


Why is this acquisition important and why should I care?

Every acquisition that Nintex makes is important. The decision to acquire a company is not one that is done over night or on a whim. It takes teams of people, countless hours to review not only the product, but the company itself to ensure that it is the right move going forward. For Nintex and Kryon, it is a perfect fit both from a product standpoint and a company culture standpoint. Here at Nintex, we want to be your one-stop-shop for everything regarding process in your organization. Adding what Kryon offers to our platform helps to meet the growing demands we hear from you, our customers. As a company, both Nintex and Kryon are committed to customer and partner success all while providing an easy-to-use, powerful process platform. What this means for you, is that Nintex is continually building on top of an already powerful platform and adding more functionality to it.

Where to next?

This announcement is still very new and there are a lot of moving parts. Over the next few months, we will see integration between the products, bringing our customers a best in class platform to tackle their process and automation needs. While we can only speculate on what is to come, I look forward to seeing how we can streamline the power of Kryon’s Process Discovery and move into automation solutions such as Nintex Workflow Cloud. Keep an eye out for more announcements from Nintex!

Final Thoughts

As a Nintex employee, I am excited about the growth of not only the company, but for the platform. As the company grows, new opportunities open for both personal and professional growth. As for the platform, I am super excited to see how we integrate these new capabilities into our already powerful platform and how I can leverage them to build out more business processes. Having more tools in the preverbal toolbox is a good thing, especially when you only need one toolbox to carry everything! Let me know what you are excited about and looking forward to in the comments below.

How To: Add Form Signature to Generated Document using Nintex Workflow Cloud

In this blog I wanted to expand on a topic I covered about repeating sections in document generation and show how we can easily add in another piece; a signature captured on a form. I get questions around this often as users want to be able to get a signature or sign-off from a user, but do not want to use up part of their subscription from their e-signature of choice. While adding an e-signature tag or image to a document follows the same approach, this post will detail how to use the Signature control within Nintex Workflow Cloud and add that to our generated document. Perhaps we can detail out how to add tags for DocuSign and Adobe Sign in another post, but for now, let’s dive in!

For this scenario, I am going to use the same process and form that I detailed in the last blog, but you can add this functionality to any process that you want. There are plenty of use cases out there on why a form may require a signature from the user filling out the form; sign-off that they received sensitive information, reviewed changes, or read a set of legal terms. In our scenario we want to validate that user read the terms and conditions of the order they are placing, and the signature is them agreeing to them. Now we can add the legal terms and the signature to the generated document (the invoice). I will cover two different ways to add the signature and explain why you would want to use each one.

Adding the Signature Control to the Form

To get started, we first need to add a new page to our form for Terms & Conditions that we can update as well as a signature control. I am going to use some placeholder text for this, but you get the idea of what we are going for! Below that we add in the signature control and set it to be required. We will leave the rest of the form as is (refer to this blog if you want to see how I set it up).


Configure the Generate Document Action

Now we need to add the signature to the generated document. We can do this two different ways. One is super simple and straightforward; we copy paste the Nintex tag into the document where you want the signature to be placed on the document.

The other is to use a placeholder image and replace it with the signature image. Before we can add a tag through the Nintex Document Tagger, we need to add the image to the document generation action.

Open the “Images” section and click on “Add Image”. Give the image you are inserting a name. Since the image is already a variable from our form, we can select File variable and then in the dropdown, select the variable you created (the name of the signature control on your form).

Adding the Signature Image to the Document

Now that we have the image available as an option in our document tagger, we can open our document and place the tag where we want it to go. That’s it, super easy!

Now let’s add a placeholder image and replace that image with the signature image so we can see the different between the two options. Place your placeholder image in the document where you want it and resize it to be the size you wish. You can also adjust other image options such as style, transparency, border, etc. Once you have everything set for the placeholder image, click on the image and then “Selection Pane” under the Picture Format tab in the ribbon. Here you will be able to rename the image with the document generation tag that you created above.


End Results

You can now save and publish your workflow and run it to see the differences between the two approaches. The first one, where we simply place the tag on the document will make the image the full width of the document.

The second option, using a placeholder image, allows us to resize and adjust the image to better fit out needs.

Final Thoughts

There are plenty of reasons and use cases that you may want to grab a signature from a user while filling out a form. I often think about Employee Handbook signoffs or all those policy signoffs that come up for review each year. It would be super easy to create a simple sign-off form and if needed, push that to a generated document that could be shared with the employee and anyone else.

How To: Add Repeating Section Data to Document Generation in Nintex Workflow Cloud

A while back a wrote a blog about getting Repeating Section Data from a Nintex Workflow Cloud form to a list in SharePoint Online. I wanted to expand upon that use case and take that same data and add it to a document using the Generate document action in Nintex Workflow Cloud. The reason for this is because I get a lot of questions around “What else can I do with the data? Can I create an invoice after some lookups and calculations?” The simple answer is, yes! So, let’s look at how we can easily accomplish this.

The Form

If you followed along on the last blog, I am going to use the same form and workflow that I built out there. If you do not, don’t worry, you can use this approach with any form where you have a repeating section and want to add it into you document generation. I went ahead and added a few more controls on the form to collect some “customer data”. See below on what was added.

The Workflow

Once the form is submitted, it is off to the workflow! I removed the actions that added the data to the SharePoint Online list for now so that we can focus on just the document generation. Perhaps we will go back and add everything together to see a full, end-to-end, use case. Another blog for another day! For now, we need to get the document template that we will be injecting all our data into. I am using a SharePoint Online library to house my document, but Nintex Workflow Cloud also has out of the box connectors for Google Drive, OneDrive for Business, Dropbox, and Box if you would rather leverage one of those. Since I know where my template is stored, I just need to configure the action with the URL of the document and store it in a variable within my workflow for later use.


Now that I have my template, I need to inject the data that I collected from form and any other data I queried along the way. When configuring the Generate document action, I need to select which type of generation I need:

  • Single PDF
  • Separate PDF
  • Same file as the template (.docx, .pptx, or .xlsx)

Next, select the template variable that you pulled in from the previous action and select the Generation order. You can have multiple templates and generate them in any order that you require. After that, give your output a name. I suggest making it dynamic so that it is unique to the workflow instance that is executing the action.


Lastly, we need to store all the generated documents into a collection variable so that we can easily perform further actions with the document. Perhaps we want to email it to someone as an attachment, or route it for approval, or e-signature.

Before we move on to the next action, we cannot forget to configure the key piece to all of this, the repeating section data! To do this, we click on the “Add repeating data button” and then navigate to our repeating section under the Start event section of our variables. You have a few options on how the repeating data can be repeated; row, table, or section.

  • Row – Will repeat the collection of data as individual rows within a single table
  • Table – Will repeat the collection of data as individual tables
  • Section – Will repeat the collection of data as individual sections within a document

For this example, we will be repeating by rows. Once the repeating data is configured, we can open the template and the Nintex Document Tagger (at the top of the Generate document action) and begin to insert our data points. To do this, we simply click on the data in the tagger, which copies it to your clipboard, and then paste it into the document where it belongs. Below is a look at how I built out the template using the customer information to create a “Bill to” section as well as how the repeating section of the invoice was setup. Pay close attention to the Start tag as it is key to the repeating data.


Once the template is tagged with all the required pieces of data and is formatted to your liking, we can setup the last two actions to store the file back into our SharePoint Online list. First, we must pull the file out of the collection that all generated files were stored in. Since we only have one, we can easily pull the file from index 0 of the collection. The reason why the files are stored in a collection is because there may be multiple documents that were generated. It also allows you as a designer to iterate through the collection and perform your required actions on each file within a single collection.

Once we have the file from the collection, you can do a multitude of actions such as send it off via email, route for approval, or even sent out to be e-signed. For this example, we are just storing it back into our SharePoint Online list using the Store a file action.


The Output

With everything in place, we can now fill out our form and see what is generated for us. Below is a snapshot of the generated documented with all my information along with a repeating section of the data from the form. You will also notice that the document title is dynamic based on the “Full Name” and “Company Tax ID” controls.

Final Thoughts

There are a lot of cool things you can do with document generation. Not only within Word, but PowerPoint and Excel as well. I want to expand this topic out a go a bit deeper next time to show how we could add lookups to our form as well as lookups within the workflow to pull in other data to add to our generated document. Even a signature from the signature control from the form! Let me know what else you want to see added to this scenario or document in the comments below and perhaps I will add it into the next article.

How To: Repeating Section Data from Nintex Workflow Cloud to Office 365

Repeating sections are great and there are a ton of use cases where it make your life as a developer easier to capture data from end users. However, when you want to move that data from one place to another, there are considerations that need to be addressed. For example, if you were to build a form in Nintex Workflow Cloud with a repeating section, the data object that is stored is quiet different than if you were to do the same using Nintex Forms for Office 365. So then how do we store the data from NWC to a SharePoint Online list and have it populate on a Nintex Form? It is fairly straightforward, but there are somethings that you will need to do in order to get things moving. Let’s dive in!

Use Case

There are plenty of use cases for this, but for this we need to have a public facing, anonymous form to be filled out and then sent to a SharePoint list so that internal employees can perform their duties. We will focus on leveraging Nintex Workflow Cloud to handle the anonymous form to capture the data and then send the data to a SharePoint Online list using workflow. The main point here is to ensure that the data stays intact and structured the same way in the form in Nintex Form in SharePoint Online as it was submitted using the Nintex Workflow Cloud form.

Setting Up The SharePoint Form and List

Before we get too deep, ensure that your SharePoint Online list is setup to capture the repeating section data (XML) in a list column. You will need to create a Multi-Line text column on the list and connect the form to it. To do this, simply open your Nintex Form and connect the Repeating Section control to the desired Multi-Line text column in your list.

This will allow us to read and write data that can be populated in the repeating section in the form. Once you have that setup, submit a test form to ensure that the data is writing back to SharePoint and you should see the XML structure, something like this:

Be sure to note the XML structure as you will need this later as you will need to replace the nodes with the data from NWC.

Now that we have the SharePoint form and list all setup, let’s take a look at Nintex Workflow Cloud and how to move the data.


Setting Up Nintex Workflow Cloud

Starting with the anonymous form in Nintex Workflow Cloud, it can be designed however you wish, but ensure that the repeating section contain the data points that will need to be populated in the SharePoint Online form. In this example, they are exactly the same to ensure nothing gets missed.

Once the form is all setup and ready to go, it is time to build out the workflow to send the data to our SharePoint Online list.

In order to send the data to our SharePoint Online list and have it populate our Nintex Form, we will need to create the proper XML structure that the form can use. We will have to use the XML structure that we got above from our list and replace the values of the nodes with the values from our NWC form. This can be accomplished by using a loop to iterate through the repeating section. Here is how we will approach the workflow:

The main focus is everything in the Action Set – Create XML Structure. Here we are building out the parts of the XML: XMLStart, XMLBody, XMLClose, and XMLtoItem. The reason we approach it this way is because we can setup the nodes within the XML (the <Item>) within the loop and setup the opening and closing nodes separately. Lastly we will combine all of the variables into one and send that to our SharePoint Online list to keep things clean. Let’s take a closer look at each step.


For this you will need to set the variable to the the first section of the XML (that you have from you SharePoint Online list) up to the <Items> node:

<?xml version="1.0" encoding="utf-8"?>


Here we will use a loop to iterate through the repeating section in the NWC form to ensure we get all of the data we need.

Within the Create a text string action that is inside the Loop for each action, we will be replacing the node values with the variables from the repeating section. Again, use the XML structure from your SharePoint Online list to accomplish this. Here is what mine looks like:

	<_0ea73348dbc9b88872765c539ab571a1 type="System.String">INSERT_VARIABLE_HERE</_0ea73348dbc9b88872765c539ab571a1>
	<_2d7f4e72a5a9b9a2df634603940a6fbb type="System.String">​INSERT_VARIABLE_HERE‍</_2d7f4e72a5a9b9a2df634603940a6fbb>
	<_779096b47884119f246fc8dc033cc15c type="System.Int64">INSERT_VARIABLE_HERE</_779096b47884119f246fc8dc033cc15c>

Once all nodes have been replaced, the last piece is to add the variable that you are storing this to is added to the beginning of the text string. This ensures that if there are multiple items in your repeating section that they are added to the end of the body. This avoids having the repeating section data show up in the SharePoint Online list in the reverse order than what was submitted in Nintex Workflow Cloud. In the screenshot, I am using the variable XMLBody.



Similar to how we setup the XMLStart variable, we want to ensure that all of the nodes are closed properly. Here is what it should look like:



Now that we have all of the parts for our XML structure, let’s put them all together so we are sending one variable instead of three! This is to keep things simple in the last step when we create (or update) the list item in SharePoint Online. Keep in mind that ordering does matter here, so be sure that your variables are in the proper order!


Sending the Data to SharePoint Online

The last step of our workflow is to send the XML to our SharePoint Online list so that it can be viewed on our Nintex Form. In my workflow, I am creating a new item in my SharePoint list. This will work for updating existing items as well, you would just need to use the Update Items action and select the correct item to update based in your conditions. Here is a look at how Create an item is setup:

The key to this is to ensure that the column in the list that holds the form XML data is updated with the XML that was pieced together in the workflow. Once everything is in place, we can test it out and see the repeating section data move from the form in Nintex Workflow Cloud to our SharePoint Online list, but more importantly, be visible on our Nintex Form in SharePoint Online!

Final Thoughts

As more and more organizations look to consolidate what tools they use it becomes important to understand how to leverage what is available to ensure that data can be usable across multiple tools and platforms. With Nintex, you can easily capture repeating form data and store it where ever or how ever you require.

How To: Branch By Stage (State Machine) in Nintex Workflow Cloud

I wrote a blog some time back going over the benefits of using a state machine in Nintex Workflow. I wanted to revisit that idea but bring it into the cloud space as so many organizations are doing today. The Branch by stage action is the same concept as the State Machine action that you may have seen in other versions of Nintex Workflow (Nintex for SharePoint and Nintex for Office 365). The logic behind it is the same, so if you have used it in the past, you know how powerful and useful this action can be! If not, no worries, I am going to explain it here. If you are looking for State Machine by Example for on-premise, check out this blog.


For this, let’s frame it as a software request and approval process. Here is the overall process:

  • The end user has the ability to select different software they require to be installed.
  • Once submitted, a task is sent to their manager for approval. The manager has the ability to approve, reject, or ask for additional information from the requester.
  • If approved, another task sent to IT for approval. IT has similar options; approve, reject, or ask for additional justification from the manager.
  • If any task is rejected, a notification is sent to the requester with provided reasons.
  • If any task is requesting additional information, it is sent one level up (manager to requester, or IT to manager).

I am not going to get into the form in this blog, but we will keep it simple for now and collect:

  • Name
  • Employee ID
  • Email Address
  • Software (from a dropdown)
  • Reasoning why software is required

One thing to call out on the form is that the software selection is within a repeating section. This is important as users are able to request multiple applications to be installed within a single request, but also because we will need to parse that data to make it usable within notifications. Let’s dive into the workflow itself.



Here is the workflow when it is minimized and collapsed down:

Seems simple, but let’s take it one section at a time.

First off, we are going to use a Loop for each action to get each software selected and the corresponding reasoning so that we can present that in notifications later in the workflow. To do this, we will select the Repeating section that we used in our Start Event Form as the collection to loop through.

Within the loop itself, we are going to use a Create a text string to concatenate all of the selected software into a single text variable. In order to keep it easier to read and formatted, I added a <p> tag:

These steps are not required to make the rest of the workflow work properly, but it does make it easier to read for those reviewing the submissions. Keep that in mind that it is not just the requester that it needs to be easy for, but everyone that is involved in the process! Now that we have the housekeeping steps completed, we can move to the approval process. Here is where we will be using the Branch by stage action.


Branch by Stage

At first glance, it probably looks like a spaghetti monster, but it is really not that bad. The Branch by stage action allows for designers to create repeatable branches of logic that can be called in any order and even reused if necessary. This means we can move in any direction as many times as needed until we exit the action. Think about it in the frame of the software approval process; a user submits a request and then it is sent to the manager for approval. If the manager approves it, it goes to the next stage, which is IT. If the manager requests additional information, it moves to the Requester stage. This allows the workflow to be designed in a very dynamic way rather than linear, thus avoiding bottlenecks or roadblocks within our workflow design. Here are the stages for the example we are building:

What happens when the manager approves the software request, but IT needs more information? IT now has the ability to send it back to the manager asking for additional justification. This keeps the workflow moving and shifts the responsibility to the proper party. Now IT does not have to track down a manager to get all the details, it is automated based on the logic provided within the workflow.

Now that we have the stages all set, we need to place some actions on each branch. For the manager, IT, and requester, we can use a task action to notify them that there is something to do. Based on the outcome of each task we can move the workflow to the desired stage. Let’s take a closer look at the manager task.



Here we see multiple outcomes (Reject, Approve, Need More Information) that each align with another branch within our Branch by stage action. Also, the task name is using variables so that it is dynamic for each request, thus making it easier for managers and IT to track and manage each request. Scrolling down in the configuration pane, we setup the notification that will be sent to the manager. This is where we can leverage the AllSoftware variable we created in the beginning of the workflow. Here is how it looks when sent to the manager:

Now the manager knows what the request is before they open the form to make their decision. Within the task configuration, there is a place to configure the task form as well. Here, we can set the form up to have a place for comments (depending on the selected outcome) as well as a list of the selected software. Again, this is not required, but gives users all the details they need to make a decision without having to jump back and forth between emails or forms.

Here is the manager task form they will see based on the above:

Once the manager has made their selection, the workflow will move to the corresponding branch. If the manager needs more information, the process moves back to the requester for additional details and then potentially back to the manager if resubmitted. Again, allowing the process to move forward without creating bottlenecks or having to restart a process from the beginning.


Everything Else

I am not going to go through every action, as many of them are setup the same way, but the idea is that the task outcomes determine where to move next in the workflow. For this scenario, the best case is that the request is approved by the manager and then IT, but we can accommodate for instances where that does not happen, and we need to go backwards.

Another way to think about this is consider an approval processes that focus on money. What happens if the amount is under a certain amount? Does it need to go to each level of approver, or can it be auto-approved? What about amounts that are large and need to go directly to a C-level? Using a Branch by stage action within Nintex Workflow Cloud easily allows for all of these scenarios to be created with ease.

Where to next?

This topic just scratches the surface on many topics. How do we capture comments between stages? How can the conversation between stages be captured? How to approve some items in the request but not all? I want to cover all of these and more, so keep an eye out for my blogs and leave a comment if there is something you want covered!