How To: Extracting XML Data from a Repeating Section

How to create an itemized list of all data within a repeating section on your form. In this blog we will discuss how to leverage Query XML, Loops, Collections, and Document Generation actions.

We have all ran into this scenario before: “I need to be able to submit multiple (insert things to submit here) but in one single form.” This is not a new concept of having a form that allows for multiple items within it, nor is the idea of how to go about collecting that data anything new. However, there does seem to be some different approaches on what to do with the data AFTER it has been submitted. Here is how I would approach this scenario, but please, let me know what you think in the comments below and what you would change or how you would go about architecting a solution like this. Let’s jump in!


I have a form that I use to request banking information. I know the bank name and location, but need to know additional information for each one. Rather than fill out a form for each bank, I can use a repeating section to capture each request and process the entire form altogether.

Things you’ll need if following along:

  • SharePoint list – data entry (form)
  • SharePoint list – create an itemized list of request
  • Document Library – the document is generated at end of a workflow (used in the second part) – more to come on this!


I am not going to go into great detail on how to design the form, but there is one specific piece that needs to be addressed. In my SharePoint list, I have multiple lines of text column named RepeatingSectionXML. This colum will be used in the form and connected to the repeating section. This allows me to capture all of the data that is being entered into the repeating section and usable within my workflow.

Here is the published form (filled out):



Now that the form is setup and we are collecting the XML data in a list column, we can move on the building out our workflow to break it apart and push it to an itemized list.

First step: Get Data from Repeating Section XML

I use a parallel action to get all of the elements I need and store them into collection variables. For the above banking example, it will look like this:

And here is a closer look at the Query XML actions:

Be sure your XPath query is accurate. I recommend using something like to test and validate your query.

Second step, now that we have all the needed data points in collections, is to simply loop through them and create a new item in our itemized list in SharePoint.

We begin our loop by pulling out data for each Bank and then getting the data from the Location collection at the same index:

At this point we have both the Bank Name and Location that was requested and can send it to the Itemized list for further processing. This is as simple as leveraging the Create Item in List action setup like this:


You’ll notice that we are storing the newly created SharePoint item ID in a variable so that we can save it and use later. Here, we may also want to consider adding some more content to the new item as we are creating it. Perhaps the {currentItem:ID}? If we add a reference to the “parent” item (the form we filled out in the beginning), we can perform lookups later on in another workflow or process to ensure updates happen if needed. Last step is to add the item ID to a collection and we can do so like this:

At this point, we have filled out a form to request additional information on some banks. This data was stored in a repeating section (XML) and we used that data to create an itemized view in another list (via query XML, looping, and create item actions). The main focus was how to parse through the XML and do something with it. For this scenario, we broke it apart and send each item to a new list. From here, you can replace all of the actions inside the loop with whatever actions you need to perform for your specific process/workflow.

In this example, we have one more step; Document Generation.

I am generating an Excel sheet of all of the Bank Names, Locations, and SharePoint IDs that will be used for lookup the additional required data. The reason I am doing this is because the information that needs to be referenced is on the FDIC website and will be scraped using out Nintex RPA offering.

How To: Auto Populate Form Controls in SharePoint Online with Nintex

We always want to make intelligent forms for our users, and one way to do that is to auto populate as much on a form as possible. This reduces the amount of time a user spends on a form as well as increases data accuracy. Win-Win all around! How can we do this within Nintex for Office 365? Quite simple.

TL;DR – Use the lookup function.

This approach will be for the Classic and Responsive designer that Nintex offers. If you are looking for how to do this in the New Responsive designer, check out this video. I will post a guide on this approach soon.


For this scenario I am going to be looking up some employee data that is in a SharePoint list. Perhaps I need to build a request form and want to pull in a user’s name and department based off of their Employee ID. We can absolutely do that with Nintex Forms. Here is my set of data:

Now let’s build out the form on our request list. For this, I am going to collect all of the same data points. I am going to set them as text fields, but rather than having my users enter all of the information, I am going to have them select their Employee ID from a drop-down on the form. If the user needs to change what was auto populated, they can still do that as we are not using Calculated Value controls for this.

The Employee ID is what will drive the rest and auto populate the form. Be sure to connect this List Lookup control to a column in your list so that you commit the data back to the list! Here is how that control would be setup for this scenario:


For the rest of the controls, we can use rules and when the lookup control has data, we can set the value using another lookup function. Confused? Not to worry, it is simple. In order to add a rule to a control in Nintex Forms, simply select the control, let’s select First Name, and click on Add Rule in the top ribbon. Here is where we want to build out the logic to lookup the First Name data from our EmployeeData list based off of the EmployeeID we selected in the drop-down.

The rule will be triggered when the Employee ID control is NOT NULL OR EMPTY. This means that the form will not auto populate until a selection has been made. This also means that each time the selection changes, it will trigger another lookup, thus updating the data!

Now, time for the lookup. When the rule is triggered, we want to set the control to the result of the lookup function. The First Name, in this case, will come from our EmployeeData list, using the Employee ID as our key. The lookup function is this:

lookup("EmployeeData", "EmployeeID", parseLookup(Employee ID), "First Name")

Let’s take a moment and break the lookup function down to something a bit more manageable.

“EmployeeData” – This is the list where we want to lookup data from

“EmployeeID” – This is the column in the lookup list that we want to filter on

parseLookup(Employee ID) – This is the value we want to filter on in the above column. This is the lookup control that is on the form. Why use parseLookup() and not just the control? When using a lookup control, the selected value also has the ID appended to it. For example, if we selected Employee ID 55555, the resulting data would look like this: “1;#55555”. We just want the value, not the ID, so we use parseLookup().

“First Name” – This is the column we want to be returned from the list we looked up and filtered. As you can imagine, this is the piece that would change for each control you want to auto populate.

If you want to read more on the lookup function, check out the Nintex help files.


From here you can easily duplicate your rule, add it to another control, and change the lookup function to return the desired data. Once you have everything setup, test it out in the preview mode that is available in Nintex Forms. You should see something like this:

Now, keep in mind that since we used text controls and rules to auto populate and not Calculated Value controls, we allow for changes when needed.

Can make changes to controls as needed

Once submitted, the data can be made visible within the request list that we created earlier.

Final Thoughts

Why use Single Line Textbox over Calculated Value? Using a SLT control allows for changes to the data, whereas a Calculated Value control is read only. Both have their uses and can easily be setup. One could even setup the SLT to be read only by setting “Enabled” to “No” in the control settings. It would result in something like this:

First, Middle, Last Name and Department are not “Enabled”

Can this approach be used in SharePoint on-prem? Yes, absolutely! Even using the Classic forms designer.

Want to take this a bit further? You could setup the form to auto populate based off of the current user! There is a section called “Common” when inserting reference into the rules. There is a reference to current user (Display Name, Email, and Login ID) that can be used.

I hope this has been helpful and pointed you in the right direction when it comes to auto populating your Nintex Forms in Office 365.

Let me know your thoughts in the comments below!

How To: Leverage Your Nintex (XML) Form Data

I get this question a lot and there are a lot of articles out there around this topic, but I wanted to clarify a few things. What is this used for? Why would I use it? Just how easy it? So let’s jump in!

Nintex (XML) Data, What Is It Used For and How Can I Use It?

The Form Data variable within Nintex Workflow (on prem, O365 it is call NFFormData) is used for unbound data in your Nintex forms. This means that any controls you are using in your forms that are not connected back to a SharePoint list column will be here. That’s great, but why would I need use this? There are many use cases on why we would want to use this everything from accessing repeating section data to not wanting to commit the data back to SharePoint. We will use the example of not wanting to commit the data back to SharePoint in this discussion.

Collecting Data without Commiting to a SharePoint Column

The idea of not commiting data back to a SharePoint list is more common than most people realize. For various reasons, we want to collect the data in an easy, user friendly format (Nintex forms to the rescue!), but do not want to create a SharePoint column for every data point. We still want to access the collected data within the workflow though so it needs to be accessible. This is where it all comes together with the Form Data variable in the workflow! So how easy is it to start using it? You probably already have access to it without realizing!

The Ease of Form Data

First and foremost, you need to be using Nintex forms to see this variable. If you are just using the out of the box SharePoint form, you will not see it in the workflow tool. Once you create a form you will see it in the Item Properties tab:

Left: No Nintex Form Data | Right: Nintex Form Data

So let’s take a look at the Nintex form. Below is a sample I put together and have 3 controls that are not connected to a list column:

Nintex Form with unbound controls

Now, let’s say we want to access the data within the workflow to update other systems or create SQL queries using the data points. Within the workflow we can query the Form Data variable (since it is XML) and target each node. So taking a look at the XML of the above form, here is how easily we can setup the workflow action:

<?xml version="1.0" encoding="utf-8"?>
	<Version />
	<Project_x0020_Number type="System.String">A113</Project_x0020_Number>
	<User_x0020_Name type="System.String">jesse_mchargue</User_x0020_Name>
	<Internal_x0020_ID_x0020_Number type="System.Int32">8675309</Internal_x0020_ID_x0020_Number>

Query XML workflow action:

Query XML Action

All we need to do is target the node we want and store it in a variable. We can then use the variables how ever we want. If you need some help building the XPath to target the node, check out the XPath Builder button in the workflow action (onprem) or here is a free online XPath tester

Here are the results for our example:

Extracted Data: 
Project Number: A113
User Name: jesse_mchargue
Internal ID: 8675309

Is it that easy?

Yes, it is that easy! Keep in mind that Form Data is only available when you have a Nintex form and you want to access the unbound data in your workflows. Of course, if it is bound to a list column, you can query the list.