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.

Advertisements
Advertisements

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:

Advertisements
Advertisements

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.

Advertisements
Advertisements

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
Advertisements

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"?>
<FormVariables>
	<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>
</FormVariables>

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.