Populating Repeating Section Controls with List Data

Part 1: Creating the Form and Lists

In a post written by Vadim Tabakman, he showed us how to parse repeating section data in a Nintex Form using Nintex Workflow. Vadim’s clever User Defined Action (UDA) queries the XML in the repeating section, extracts the text and stores it in variables for later use by our workflow. This concept has proven invaluable on several workflows Synergy has built for our customers.

But what happens when we want to do the reverse? In this scenario, say you want to create an onboarding form which automatically populates the controls within a repeating section with a new users’ default resources. This would include Resource Name, Description, and the administrator for a resource. The default resources will be dependent on the user’s role within the business, determined by their department.

Challenges:

We have a few problems to overcome. Controls bound to a column cannot store more than a single value, so repeating data presents a problem. If a repeating section is unbound, the data is effectively encapsulated within the XML, making accessing the data more challenging. In the scenario I’m about to present, the amount of data in each repeater can vary significantly, so creating a simple lookup will create performance issues. Finally, the customer in this case was averse to using JavaScript due to their
limited ability to support it.

Lists

Department

First, I created a Department list to store departments which will be used in the form. This has a Single Line of Text column, which is the Title column which has been renamed. 
  Figure 1: Department List

Resources

Secondly, I created a Resources list. This has a Resource column (renamed Title column), a Description column (Multiple Line of Text), a Resource Administrator (Person or Group), and finally, the Department column. The Department column is a Lookup configured to pull one or more values from the Departments list. In our customer’s particular case, there were over 400 resources!

Figure 2: Resources List

Onboarding Form

I created a simple tabbed form for this post (again, thank you Vadim). In the Employee Information panel/tab (at top), I am using Single Line of Text columns for Employee ID, First/Last Name, and Job Title. Notes is a Multiple Line of Text (MLOT) column, and Department is a Lookup configured to pull values from the conveniently titled Department list. This lookup only allows a single choice. These controls are bound to Onboarding Form columns.

NOTE:   The Department value could also be a choice control/column. I chose to create a lookup to prevent my customer from having to update the values in the Choice
Column within the list, instead allowing values to be added or removed from the Department list).

Figure 3: Onboarding Form in Forms Designer

Onboarding List Columns

Figure 4: Onboarding List Columns

The second panel/tab has a Repeating Section control. This control is bound to a Multiple Line of Text (MLOT) column titled Default Resources. It is important to note, when doing this, the MLOT must be set to Plain Text or it will not let you bind the Repeating Section to the MLOT column.

Figure 5: Default Resources Column Setting

Figure 6: Repeating Section Name and Binding

Within this, I have a Resource Name Single Line of Text control, a Resource Administrator Person or Group control, and a MLOT Description control. For Resource Name and Resource Administrator, I have named the controls (ResourceName and ResourceAdministrator respectively).

Figure 7: Resource Name Control Name

However, I chose not to name the Description control. While I would recommend naming your controls, as it makes it easier for the workflow configuration, the steps outlined in this article can be done without naming controls. I’ll show you why naming the controls is helpful in just a bit.

Figure 8: Description Control (unnamed)

In order to build the workflow, you are going to need some information from the repeater. To do this, create an item and populate it with some data. In the Repeating Section Controls, put in some easy to remember values. This will help display the start and end tags and the content within the control, which is especially important with unnamed controls.

Figure 9: Assigned Resources Sample Data

When we save the item, we get back some data. The bound controls on the Employee Information tag get stored in the columns, and the data from the Repeating Section is stored to the Default Resources MLOT column as XML.

Figure 10: Sample Data

Since that is impossible to read, the data that was returned is as follows:

<?xml version="1.0" encoding="utf-8"?><RepeaterData><Version /><Items><Item><ResourceName type="System.String">TestResourceName</ResourceName><ResourceAdmin
type="System.String">i:0#.w|synergyjason</ResourceAdmin><_x0031_100a024-4518-4b10-8a57-d51408654ed5 type="System.String">Test Description</_x0031_100a024-4518-4b10-8a57-d51408654ed5></Item></Items></RepeaterData>

So for our three controls (Resource Name, Resource Administrator, Description) we have the following XML to concern ourselves with:

Resource Name: <ResourceName type="System.String">ControlDataHere</ResourceName>

Resource Administrator: <ResourceAdmin type="System.String">ControlDataHere</ResourceAdmin>

Description: <_x0031_100a024-4518-4b10-8a57-d51408654ed5 type="System.String">ControlDataHere</_x0031_100a024-4518-4b10-8a57-d51408654ed5>

To quickly recap, I named the Resource Name (ResourceName) and Resource Administrator (ResourceAdmin) controls, and did not name the Description control. Because I named the first two controls, we get easy to read start and end tags. With my unnamed Description control, we get the less simple hex for the control (_x0031…). So it’s still possible to use unnamed controls in your repeater, but it’s going to be a bit messy, thus the recommendation to name your controls.

We now have the XML we are going to use when populating the controls within the Repeating Section. And now for the workflow.

Part 2: Workflow to populate the Repeating Section with list data

In Part 1 of this post, I showed you how to create a few lists and a Nintex Form with a repeating section. That repeating section stores data within a plain text Multiple Line of Text column as XML. I am now going to show you how to build the workflow to query list data based on information in the form and, when returned, automatically create rows within your repeating section for each value that is returned.

Our requirements for this workflow are as follows:

• New Employee information will be populated in the Employee Information tab of the Nintex Form by a manager who has hired a
  new employee, including the Department he or she will work in.
• Each department or business unit has default resources assigned to a new employee in that department.
• The workflow should query the Resources list and return items tagged with the user’s new department, and automatically create a
  row in the repeating section for each returned resource.

Workflow Configuration

Query List

So, we start with a Query List action. The Query List action will query the Resources list when Department is equal to the Department value selected by the user in the form.

Figure 1: Query List with Filter

Once we have our filter set up, we need to return the values needed to populate the controls in the Repeating Section. For this, some Collection variables have to be set up.

Figure 2: Returned Fields and Variables

For Each

Now that we have our data in variables, we need to extract the individual values in each collection. We’ll start with a For Each action, and get the subsequent values using a Collection Operation. To start with, we will loop using the collection for the Resource Name (the choice here is arbitrary). As the data in the list is text, we’ll use a Single Line of Text type variable. Finally, because we need to repeat this process for the Administrator and Description, we’ll create an Index variable using a number type variable.

Figure 3: For Each Configuration

Collection Operation 1

Now we need to move on to the Resource Administrator and Description values. To extract these, we will add a Collection Operation within the For Each action. The first Collection Operation action will ‘Get’ values from the Resource Description collection and store them in a text variable. Because the column in the Resources list is a Multiple Line of Text column, I created a variable of this type, though a Single Line of Text column would probably also work. Use the index you created in the For Each so the collection
operation knows when to start and stop processing values.

Figure 4: Resource Description Collection Operation Configuration

Collection Operation 2

Now that we have the Resource Descriptions, we can process the Resource Administrators, again using a Collection Operation action. As the data type for this is a Person or Group, you’ll need a Person or Group type variable to store the result. Again, use your Index to tell the action when to start and stop processing values.

Figure 5: Resource Admin Collection Operation Configuration

By now, you should have something that looks like this:

Figure 6: Workflow Designer

Build String

We have now extracted all of the values from the collection variables, and have the data stored in individual variables of the appropriate data type. We now need to insert that data into the XML from our Repeating Section. To do this, we need to use a Build String action, again inside of the For Each, as we are building this string for each row of data.

Since we have an understanding of the start and end tags for our controls within the Repeating Section from Part 1 of this post, we will build on that by inserting the variable data we captured in the above steps. Between the tags for the three controls, insert a reference using your workflow variables from our previous operations. Store the results in a Multiple Line of Text variable (I called mine mlotXMLSnippet).

Figure 7: Build String configuration

Pro Tip: In my resources list, you savvy SharePoint types might have seen some of the description values have non-web compliant characters (specifically, an “&” in my sample data). If inserted into XML, this will create a problem which prevents the repeater data from being displayed. To overcome this and effectively ignore the special characters, I have wrapped my variable reference in <![CDATA[{WorkflowReference}]]>. This instructs the XML to ignore the content contained in the string. If your data
does not contain any special characters, you can ignore this step.

Collection Operation 3

Finally, now that we have our individual XML strings for each row of returned data from our query, we need to add them to a new collection. For this, I created a new Collection variable, and am using an Add operation. The data I am adding comes from the result of my Build String action, which was stored in the mlotXMLSnippet variable.

Figure 8: Add Collection Operation

Set Field Value

Finally, we need to take all of this processed and assembled data from our query and insert it into our list item. To do this, I have used a Set Field Value action, this time outside of the For Each action (we only need to do this once).

The column I am updating is the Multiple Line of Text column my Repeating Section control is bound to, called Default Resources. The XML string you see here comes from the test value we created in Part 1 of this post, and contains the XML version, encoding, and the Items open and close tags in our XML. Inside of that, we insert the XML Collection we created in our final Collection Operation action. This reference to the XML Collection variable belongs between the opening <Items> and closing </Items> tags.

Figure 9: Set Field Value Configuration

Your workflow should look something like this:

Figure 10: Workflow Designer View

Testing

Now it’s time to test. If everything is configured properly, after workflow execution the query should populate the repeating sections. If you are showing the Default Resources Multiple Line of Text column, the list item will look a little messy. In the solution we built, we hid the MLOT column from the default view, and created a debugging view should someone wish to look at the XML.

Figure 11: Multiple Line of Text column showing list data inserted in the XML

Here is where Nintex Forms performs some magic. Now that the XML is in place in the column, when the list item is opened (and assuming you don’t have any mistakes in your workflow configuration), you get repeating sections populated with your list data. Sweet!

Figure 12: Populated Repeating Section

Post by Jason Blair, Nintex vTE at Synergy, a Nintex Premier Partner. Check us out for more info at www.synergyonline.com