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!

Use Case: Return to Work Using Nintex Workflow Cloud

With everything that is going on in the world these days, many organizations are looking to get back in the office for a variety of reasons. Whether it is to boost productivity, collaboration, or simply to provide employees with an alternative place to work that is not their dining room or couch, organizations are carefully opening their offices for employee to return to work. As new processes and protocols are put into place, one of the first things that I am seeing organizations do is ask employees to fill out some type of form stating that they acknowledge the potential risks, sign-off they are not showing symptoms, and assist with the smooth transition back to the office.

Like everything else I do, I look at this process and wonder how it could be streamlined and easily adjustable based on the needs of the organization. Nintex Workflow Cloud to the rescue! For this use case, I built out a simple form asking for some basic employee information, when they want to return to work, and a questionnaire. Once submitted, the workflow routes to their manager for review and then ultimately generates a document that can be kept for records. So, let us take a look at the template and discuss where we can improve upon it if needed.

Before we dive in, you can go off to the Nintex Process Accelerator Gallery and grab this Return to Work template and import it into your Nintex Workflow Cloud tenant.


The Form

Let us start with the form. I built this around simplicity but could easily use a form template that you have today. In the first section we are asking for some basic data from the employee such as name, email, work location, and expected return date as well as manager information.

The second part is a questionnaire that I pulled together based on some other examples that I have seen. I kept them simple “Yes/No” questions to avoid having users spend too much time having to fill this out. There are plenty of examples out there if you need something to reference, but I would consult your internal leadership teams to understand what questions you want or need to pose to your employees.

That is the form template that I built out; nothing fancy, but it collects the data that is required to make a decision about the employee returning to work. Now that we have the form setup and ready to go, let us look at the workflow that will run when submitted.


The Workflow

Just like the form, I approached the workflow with simplicity in mind, however, there are a few things that I felt needed to be done. First off, I formatted the Expected Return Date to be human readable. Why do this? No one wants to read a date in a format like “DDMMYYYY::HH:mm::ss-UTC”, something like MMMM DD YYYY (April 22 2021) is a bit cleaner and easier to read. From here we move into the task that will be issued to the manager. If you followed along and downloaded the template from the Nintex Gallery, you will notice it was set to [[Employee Email]]. This was done so no one accidently started emailing their manager!

Nintex tasks are easy to configure, but for review, I setup 3 different outcomes: “Reject”, “Approve”, and “Approve future date”. The first 2 outcomes are straightforward enough, but I added a third option if someone wanted to stagger employees coming back or needed to get employees back earlier. Looking at the task form, it is setup the same way as the start event form but with the added Outcome control and a New Return Date control for when “Approve future date” is selected.

In order to accomplish this, we use some basic rules in the form. The rule is setup as below:

The rest of the task form is read only so that the manager or reviewer can see the content but does not have the ability to alter the data. Last piece of the task action is setting up the actions for each outcome. For “Rejected” we are going to simply end the workflow. For both “Approve” and “Approve future date” we are setting the [[ReturnDate]] variable based on the outcome. This makes any further actions are utilize the return date streamlined as it only must reference one variable and not different variables based on the outcome. At this point, our workflow looks like this:

At this point you could end the workflow with some notifications and call it a day. I went one step further and added some document generation so that everyone can have a copy of the collected data. I did not add in any e-signature but will cover that in the last section. If you have not worked with Nintex DocGen, you do not need anything else other than a template to write the content to. If you want to use the sample document that I have in the Nintex Gallery, you can download the template here: Return To Work Template

For this example, I stored the template in OneDrive for Business, but Nintex Workflow Cloud can easily be setup to leverage Dropbox, Box, SharePoint Online, or even Google Drive. Using the Get File action, we point to where the template resides and store that to a variable [[DocGenTemplate]] so that we can easily reference it later. Next, comes the generation of the document we want. Using the template, Nintex Workflow Cloud will populate the template with all the necessary data based on how it was tagged.


Document Tagging and Generation

In order to get data into your document template, open the Generate Document action and click “Open Nintex Document Tagger”. From there, a new window will provide all the various tags that can be copied and pasted into the document. These tags range from data collected in the start event (form in this scenario), data from a task, or context data such as current date and time. Once all the required data points have been added into the document, format the document as needed and then save it (back to the cloud platform).

The last piece is to store the generated document(s) into a Collection variable. This is done because there may be multiple documents and will be stored as a collection which allows for looping logic to pull out documents one at a time. For this example, the variable [[ReturnToWorkDocGen]] does just that. Now all that is needed is to store the final document(s) somewhere. For this, OneDrive for Business will be used again. When completed, the workflow will look something like this:

Final Thoughts

This is a simple example of how an organization could possibly implement some lightweight process around getting employees back to work. Of course, like anything, there are a multitude of other ways to accomplish this and more data that could be collected. Some things that I would consider and implement with this would be:

  • Manager Lookup – Have the form automatically lookup the user’s manager information using a Data Lookup against Azure Active Directory
  • Workflow Logic – Have requests be auto approved or denied based on certain business logic. This would help managers focus on the requests that truly need attention.
  • E-Signature – Have both manager and employee sign-off on the document once it is generated to ensure that everything is accurate.

I am sure that there are other areas or different approaches that could be taken, but this example can easily be modified to fit many different uses and needs by leveraging the power of Nintex Workflow Cloud. Let me know where you would add to this or what you have seen rolled out.

Getting Started: Setting Up Nintex RPA Chrome Extension

Continuing the conversation from last time where we discussed Setting Up Nintex RPA, we will dive into another piece that may be helpful as you build out automation using Nintex RPA. This next topic of the series will cover how to install the Nintex RPA Chrome Extension, which allows you to target objects inside of Chromium-based browsers.

Installing Nintex RPA Chrome Extension

We can add the extension to both Google Chrome and Microsoft Edge if desired. First, let’s take add it to Google Chrome.

  • Launch Google Chrome and navigate to
  • From here, click on “Add to Chrome”.
  • You may be prompted with a pop-up, if so, simply click “Add extension”.

Now let’s add it to Microsoft Edge.

  • Start by launching Microsoft Edge
  • Click on the ellipsis in the upper right corner and then click on Extensions.
  • You will then click on Chrome Web Store to be redirected to the Chrome Web Store.
  • Click on “Allow extensions from other stores” in the banner at the top of the screen.
  • Click “Allow” to confirm your selection.
  • Navigate to
  • From here, click on “Add to Chrome”. Yes it says add to Chrome even in Microsoft Edge.
  • You may be prompted with a pop-up, if so, simply click “Add extension”.

Nintex RPA Extension Requirements

In order to ensure the extension works properly, there are a few things to consider and ensure are set before execution. Here is a list of requirements

  • Nintex RPA version 16.5.5 or higher.
  • Google Chrome Version 75 or higher.
  • Microsoft Edge Version 83 or higher.
  • Browser zoom set to 100%
  • Windows Display Scale and layout set to 100%
  • Windows Display Make text bigger set to 100%

For more details on Nintex RPA Chrome Extension, be sure to check out the Nintex Help files.