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.

Advertisements

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.

Advertisements

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.

Advertisements

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.

Advertisements

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.

Advertisements

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.

XMLStart

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"?>
<RepeaterData>
<Version>1.0</Version>
<Items>
Advertisements

XMLBody

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:

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

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.

Advertisements

XMLClose

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:

</Items>
</RepeaterData>

XMLtoItem

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!

Advertisements

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.

Scenario

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.

Advertisements

Workflow

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.

Advertisements

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.

Advertisements

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.

Advertisements

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.

Advertisements
Advertisements

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.

Advertisements
Advertisements

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.

Advertisements
Advertisements

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 https://www.nintex.com/chrome.
  • 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.
Advertisements
Advertisements
  • Click on “Allow extensions from other stores” in the banner at the top of the screen.
  • Click “Allow” to confirm your selection.
  • Navigate to https://www.nintex.com/chrome.
  • 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”.
Advertisements
Advertisements

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.

Getting Started: Setting Up Nintex RPA

Robotic Process Automation has been around for the better part of the last 20 years, but has really taken off and gained more attention in recent years. There are a lot of solutions out there for just about every possible need or business use case, however how do you decide what to go with or how much effort is involved in getting something built? I am not going to go into detail around all of the various options out there, however I do want to highlight how easy it is to get up and running with Nintex RPA. In this series I will be discussing how to setup everything from Nintex RPA Central to the Nintex Gateway, as well as providing steps on building out your first Nintex RPA Botflow, and then ultimately expanding the process to allow data to pass from Nintex Workflow Cloud to Nintex RPA through the Nintex Gateway. There is a lot to cover, so let’s dive in!

One thing to note before going to far, if you are looking for up-to-date information or latest release notes, please go to https://help.nintex.com/en-US/rpa/.

What You Need

In order to get started, you will need to following pieces as you follow along:

  1. Valid License Key – If needed, you can get a trial at https://www.nintex.com/trial/#rpa
  2. Latest Version of Nintex RPA Central and Nintex RPA Bot – These can be found in the Nintex Customer Portal or on the Product Release Notes Page in the Help Files.

We will get to the Nintex Gateway and Chrome Extension a bit later, but for now, this is all you need to get started.

Installing Nintex RPA Central

First, we need to start with Nintex RPA Central in order to activate the license and set the stage for Nintex RPA Bot. Log onto the computer where you wish to deploy Nintex RPA Central with an account that has local administrator rights. Keep this account handy as it will be setup as the administrator for RPA Central and will need to be used when activating the license. Launch the installer and select where you wish to install, then click install. Simple really. Nintex RPA Central does install Microsoft SQL Server 2017 Express along with .NET Core Runtime.

Once RPA Central is installed, you can enter your license key. If RPA Central does not launch automatically, you can manually start it from the Start Menu or from the Desktop shortcut. You should be presented with this screen:

Here is where you want to paste your license key and click submit to activate your license. Again, be sure that the user that is logged in, is the administrator account that installed Nintex RPA Central. Another thing to be aware of is that Nintex RPA Central will communicate with its servers to validate the key. This means that the machine will need to be able to communicate out and it will not be blocked. For a list of endpoints, please check out Nintex RPA help documentation for update details.

Advertisements
Advertisements

Now that Nintex RPA Central is activated, you can assign it to a URL, add a port number, and select a security certificate. To do this, click on Settings in the top navigation bar and then License and Subscription side navigation menu. Click on the ellipsis next to the Nintex RPA Central URL (defaulted to http://localhost).

From here, you can set the hosted URL, add a port, and select your security certificate. When updating the URL, keep the new URL handy as it will be needed to connect Nintex RPA Bot to Nintex RPA Central. For more details, check out Nintex Help files.

Install Nintex RPA Bot

If you do not have Nintex RPA Bot already downloaded, you can go to the Dashboard within Nintex RPA Central and click on the Bots side navigation menu.

Click on Add Nintex Bot in the upper right corner and then the blue Nintex Bot button to download it. Once downloaded, click to run the installer.

When installing Nintex RPA Bot, you can update the directory where it is installed. Also, .NET Framework and MS Access Database Engine 2016 will be deployed during installation. For more details, check out the Product Release Notes. Once installed, Nintex RPA Bot will start and you will need to provide the URL for your installation of Nintex RPA Central. This can be done by clicking the gear in the bottom right corner of Nintex RPA Bot. Simply give your bot a name and provide the URL to Nintex RPA Central and click Request Access.

Advertisements
Advertisements

Back in Nintex RPA Central, click on the Bots side navigation menu to see your list of bots within your environment. Find your newly requested bot and click on the ellipsis for that machine to grant access. That’s it! You can now start building automation with Nintex RPA.

Final Thoughts

Installing Nintex RPA Central and Nintex RPA Bot is straightforward but there are a few things to be aware of while setting everything up. Here is a quick list of common things that I see a lot and you should be aware of:

Save and Continue Your Nintex Workflow Cloud Forms

This feature has been asked for countless times and for good reason. There are times when a form is too long or you need to gather other data to provide within the form, and need the ability to save it in it’s current state and come back to it later. Well, now you can do exactly that with minimal effort. Let’s take a look at how to set this feature up and where your saved forms go.

Setting Up Save and Continue

First and foremost, you will need to have your Nintex Workflow Cloud workflow have a start event set to a form. You can also set the form to only be accessible by authenticated users or anyone with the URL. Keep in mind that if a user wants to take advantage of the Save and Continue feature, they will need to be an authenticated user (more on that below). The form, however, does not need to be set to authenticated users in the tenant. This means that an anonymous user cannot save the form. The reason for this is because saved forms will appear in the My Nintex tab within the Nintex Workflow Cloud tenant, which the user will have to have access to in order to complete and submit the form.

Enabling Save and Continue

In your form where you want to enable the Save and Continue feature, click on the action panel where the submit button is located.

Advertisements
Advertisements

This will open up the action panel settings and allow you to toggle Save and Continue for this particular form. That’s it!

My Nintex Tab

Setting up Save and Continue for Nintex Workflow Cloud forms is not difficult, but where do the save forms go? This is where the My Nintex tab within Nintex Workflow Cloud comes in. Once you have a form filled out and wish to save it for a later time, click the Save and Continue button. This will save the form, but not close it.

Advertisements
Advertisements

In order to get to your saved forms, simply click on the My Nintex tab in the upper right corner within Nintex Workflow Cloud. From here you can easily see all of your draft forms and continue filling out the remaining controls.

Final Thoughts

This new feature allows users to begin filling out forms and save them in their current state for a later time, and this ask comes up countless times! There are a few things worth noting. The draft form is only stored for 30 days. This means after that time, the form is deleted and would need to be filled out from the beginning again. Another piece to remember is that you will need to be logged in as an authenticated user in order to save your form. Even if it is an anonymous form, if you want to save it, you need to log in.

How Easy Are Repeating Sections in Nintex Workflow Cloud?

A while back I wrote a blog about Creating List Items from a Repeating Section with Nintex Forms. The idea was to have a single form collection multiple items and then through querying XML, send each item to an itemized list. This is something that I see a lot of in SharePoint Online, but with the recent update to Nintex Workflow Cloud, I wanted to look at how easy it would be to accomplish the same thing in Nintex Workflow Cloud.

Scenario

Same as before, I want to create a form to collect my items and then send each item to a list within SharePoint Online to be processed further. If you followed along last time, we can use the same list. Here are the columns I created for my list:

  • Date of transaction (Date)
  • Description (Single Line Text)
  • Amount (Number)
  • Vendor (Single Line Text)

As you can imagine, these are the same controls I put on my form in Nintex Workflow Cloud. Just keep in mind that all the controls you want to repeat, must be in the Repeating Section. Here is my form for reference:

Advertisements
Advertisements

The Workflow

When I did this in Office365, I had to use a combination of Query XML and Collection actions to get the data into a workable format and then into the Create Item action. Not overly difficult, but begs the question of can we make this easier? The simple answer, yes, we can! With Nintex Workflow Cloud the workflow is much more straightforward because we can use the data object that is created by the Repeating Section right in the Loop for each and Create an Item action!

How does that work? In your Create an item action we will be navigating to the site and list where we want to data to go, and then select the data points we want to populate.

Once we have all of data points selected, we can insert the corresponding variable. This is done by selecting “Loop for each” to the left on the Insert variable pane and then selecting the object, current item, and finally the variable you need.

That’s it! Really! No querying the data object, no get item from collection, none of that. Once everything is mapped to the correct column in SharePoint, we can test out our form and workflow to see if we can replace the old Nintex for Office365 form with the shiny new Nintex Workflow Cloud form! Here is my test form and corresponding dataset in SharePoint Online.

Advertisements
Advertisements
NWC Form
Data in SharePoint Online

Final Thoughts

As always, there are many ways to approach this, but I wanted to showcase how we can take an existing solution in Nintex and make it even better with some of the cool new features in Nintex Workflow Cloud. This approach also opens the door to pushing itemized data into a variety of other platforms through the out-of-the-box connectors or a custom built Xtension. Nintex Workflow Cloud allows your processes to be automated no matter where they need to go.

How To: Delete A Nintex For Office 365 Workflow

There are many reasons that we may need to delete a workflow from our environment but most of the time it is just not needed anymore. Perhaps it was used for a test or even a single use effort to mass update data. Whatever the reason, removing the workflow from your environment is best practice as it frees up resources and keeps your environment clean.

Finding the Workflow

In order to delete your workflow, simply locate the site and list or library that is resides on and navigate to it. In the list or library ribbon, you will see Nintex Workflow. You want to start here and click into it to see your workflows for that object.

If you are looking for a Site Workflow, you just need to navigate to the Site Contents and scroll down to the Nintex Workflow for Office 365 app and click on that.

Advertisements
Advertisements

Deleting the Workflow

Once you have navigated to the object of where your workflow resides, click on the ellipsis to the right of the workflow and select delete from the options.

You will be prompted to confirm your selection just to be sure you really want to delete it. Keep in mind that this is permanent!

That’s it! You’ve successfully deleted your workflow.

Advertisements
Advertisements

Final Thoughts

Keep in mind that deleting a workflow is permanent. Meaning that you cannot get it back once it has been deleted. I would recommend that you take an export of the workflow and any corresponding task forms in the event that you need to reinstate everything.

Leveraging Nintex Workflow Cloud Component Workflows

When it comes to automation, many times we must streamline processes by removing repetitive steps. We do it all the time by grouping similar functions into a single group of concerted efforts. We can do the same thing when it comes to our workflows that we create with Nintex by using Component Workflows.

If you are unfamiliar with Component Workflows within Nintex Workflow Cloud, take a moment to check out this help file. If you don’t want to read that article, just know that component workflows are workflows that can be called from another workflow or from an HTTP-capable service or application. This means I can call this workflow from many different sources and leverage it in multiple processes. That is exactly what we are going to do!

Scenario

Request for Information (RFI) is a simple process where one user or group requests information from another user or group. This process may occur in a variety of other processes such as project work, reviews, onboarding, just about any process where clarification may be asked or required. Now we could simply add the logic into our existing processes, but what about creating a simple, straightforward RFI process that can be called at any time? This would allow us the ability to manage parts of the process much more effectively and allow for any process or application to leverage this as well.

The Approach

Like all good processes, let’s start by defining what we need before jumping into the designer! So, what do you need? User information? The question? What about supporting documentation? Your process may be different, but let’s start with these:

  • Question – what we are asking
  • Email Question To – email address of the user that will provide the information
  • Your Email Address – in case there are follow-up questions
  • File Upload – so we can share any documents for clarity

Again, you may want to add in more for your scenario, but this will be enough for now.

The Workflow

Let’s start with the Start Event (obvious choice here) of Nintex Component Workflow. We are going to need to create start event variables to catch the elements that will be passed in. I am going to create the four that I listed above:

  • Question – Text
  • RequesterEmail – Text
  • Approver1Email – Text
  • FileUpload – Collection

I am also going to create a variable for all the responses (we’ll call it allResponses) as well as another email address (ResponsibleEmailAddress) variable just in case there is a change. These two variables will be workflow variables and setup as an output for this workflow. That’s right, you can setup outputs for your component workflows to pass back once they are completed. Think about that for a minute! This means you have break up larger workflows into more manageable pieces and then use each, dare I say, component, wherever it is needed, even if it is within other workflows!

I have my RFI workflow setup with a State Machine to assist with the back and forth between the user(s) asking the question and those that are meant to answer it. I even set it up to all for changes to the responsible party if that changes.

Request for information

With these sorts of requests, there times where the two parties involved have a back and forth conversation and this is where the state machine comes into action. I can capture each response, from both the requester and the submitter and display that in both email notifications as well as on the task form. This allows me to present all the information to both parties so that they can quickly respond with the correct information. Here is what the form would look like after a few rounds for responses:

Task form with multiple responses

Connecting it to other workflows

Simple Start Form

For this simple use case, I created a responsive form to capture all the details needed to kick off this process. You could have this as a standalone solution or process, or a part of a larger process that leverages the RFI component workflow to manage the back and forth conversation. In either case, you can see how easy and powerful component workflows can be in building out your processes in a more manageable way.

Final Thoughts

There are a lot of ways you could approach this, and component workflows are just one of the ways. Component workflows allow for other workflows as well as HTTP-capable services and even other applications to communicate with it, thus extending your processes to include more within your organization!