Jesse McHargue

Going Into Automation? Start Here Not There

We talk a lot about automation here on this site and for good reason, it is a passion of mine! However, there are certain areas that often get overlooked on the journey towards process automation that I wanted to discuss further.

Just the Bullet Points

I could talk about automation and everything surrounding it for a long time. I enjoy helping organizations in their journey when evaluating technologies and how it fits into their organizational efforts. However, let’s boil all of this down to some fine-tuned bullet points first:

Define your automation goals – This will help determine what technology suits your organization the best rather than the specific use case. No one wants to add more products that are only used for one thing.
Understand the process – Ensure that you know the process that you are looking to automate. This helps by including a larger audience when defining the process and understanding all that are involved.
Build a larger team when evaluating – Just as including a larger audience when defining a process is important, having a diverse team evaluate automation technologies can help determine if a technology is a good fit and can be used in other areas within the business.

These bullet points may seem simple or obvious, but they lead to a smoother transition into automation as well as early adoption of the technology. When you add all of this together, you can then see a much faster and larger ROI from your automation efforts.

Advertisements

Let’s Have a Conversation…

Most organizations believe that processes that they automate are automatically improved due to it being automated. While this can be true, often it is not. Processes need to be assessed, documented, mapped, and continually improved upon both prior to automation efforts as well as afterwards. If we think of a process that is poorly designed and is prone to errors, automating that process is only going to accelerate those errors. This generally is spawned from an overall lack of understanding of the process. So, then our first step in any automation effort should be to ensure that the process we want to automate is at the very least, documented and understood.

Understood by whom? The ones executing the process or the ones developing an automated solution? If you are thinking it needs to be both, then you are correct. It is important that everyone involved, from those performing the actions within the processes and interacting with the automated solution to those that are developing the automated solution, understand the process end to end. This is critical because as someone that interacts with the process, they need to know what to expect and what and where automation plays a part in the process. For those that are developing the automation, they need to understand what roles users play in the process and how the solution interacts with them. This leads to another point; building a team around your automation efforts.

When starting to evaluate automation, most organizations direct their IT staff to go out a look for automation vendors with little guidance on what to look for, or to look for something that addresses one need. While this is an acceptable place to start, I would argue that it is important to see what other areas within the business can benefit from an automation technology. When one team or business unit is the only one involved, their focus is on solving their needs first, and everything else afterwards. If you are looking for other places to find potential use cases, check out this article on Beyond the low hanging fruit of process automation in IT and HR .

By having more than one team evaluating a technology, you allow for other key business units to get involved and provide their feedback on what is important to them and solve more use cases. Additionally, this gives the organization more users that would be evaluating the technology and thus thinking of other use cases that can be solved. Once an automation technology has been selected, building out solutions will be easier and potentially faster. Since more have people have been exposed to the capabilities of the technology and have been thinking of how they can leverage it to solve their business problems, deployment time can be reduced.

What process should be automated or used when evaluating automation technologies? This is another question that I get a lot and see organizations struggle with. Many times I begin to ask more refining questions like I discussed above. Is the process documented and defined? Do the people that are evaluating the technology understand the process? If not, organizations will quickly fail at evaluating technologies properly or worse, make a selection that does not truly address their needs. Another great article to check out is To automate, or not to automate, that is the question, and it covers the importance of process management as it relates to process automation.

Final Thoughts

These are a few examples that I have seen over and over again when I talk with organizations as they are evaluating automation. There are a lot of misconceptions too, but perhaps that is another article for another time! In the meantime, what other areas that you have ran into and found to be impactful to your business? What do you know now that you wish you would have at the beginning of your automation journey? Let me know in the comments below!

How To: Create Threaded Task Comments With Nintex Automation Cloud

Hey everyone, back at it again with a quick “How To” guide for Nintex Automation Cloud. This time we are going to focus in on creating threaded task comments so that task approvers can see previous comments in a single view. This comes in handy for a variety of reasons and is something that many users may have leveraged in the past when using Nintex for SharePoint. So let’s dive in and see how to build this out!

The Use Case

In order to frame this better, we are going to follow the use case of a request for information. The process allows users to submit questions to be reviewed and answered. Upon review, comments can be added, questions can be redirected, or requests can be sent back to the original user to further details. All comments along the way are captured and presented back in a threaded view for subsequent tasks for review. This allows all parties involved to see what was said, by whom, and when.

Start At The Beginning

For this process, I decided to use a simple form to capture some information from our user and route for review and answers. Here we see the form with controls for the Question, who to Email Question To, a place to provide their Email address, and an additional place for any required documentation to be uploaded. While I am using these simple controls to demonstrate this use case, your process may have more complex requirements and rules built in. For example, if this were an authenticated form, there would be no need to require the users email address.

With these pieces we can now jump into the workflow side of things and see how to move this between the approvers and the user that submitted the request.

Advertisements

The Workflow

Like everything else when it comes to process automation, there are a lot of different ways that we can build this out. You may have a form start event (something like I built out above), or you may be using a Component Workflow and pass the form data (from another workflow) to it. This is a great approach when you have multiple entry points or perhaps a custom built front end that you want to integrate with. I am going to take the Component Workflow start event approach so you can see that. To start, we want to select the Component workflow start event and create our variables for each of the above controls.

With the variables setup, I can now use a Nintex Automation Cloud form to collect and pass the data or another mode of data capture. As a part of the workflow, the first thing that needs to be done is to create and set a workflow variable for Responsible Email so that we can send the inquiry to them. We can also use the same variable to make any further updates as the process moves along while keeping the original data intact. From here we move into a Branch by State that allows for the process to move between various stages (or states) that we define. In our scenario we will keep it simple and create two branches; one for the Inquiry and the other for the Requester. This will represent the initial branch that they inquiry follows.

In the above scenario, we present the inquiry to the designated user by using a Task action within Nintex Automation Cloud. The task is setup with three different outcomes that will guide the process to the next step. The possible outcomes are: Need More Info, Answered, and Not Responsible Party. If the assigned user selects Need More Info, the process will move back to the Requester and prompt the request for additional information. If the assigned user selects Not Responsible Party, the user will be prompted to provide a new user in which the task can be rerouted to and thus restarting the Inquiry stage. When Answered is selected, the process ends.

Advertisements

Each outcome of the task moves the process to another part but before the workflow moves we capture the comments that were provided in the task response. This is done by taking the Task comments and adding them to a workflow variable, allResponses. I am also adding some context to the string such as the respondent email address, current date and time, and some HTML tags to help ensure that each response is properly formatted on the subsequent task form. This will allow me to take each response and concatenate them together in an orderly fashion to present on a task form or in an email.

The assigned tasks for the requester follow the same approach; after the provided outcome, the workflow captures all of the responses in the workflow variable and then moves the process to the appropriate next step. For the requester, their outcomes are limited to either provide additional information and Resubmit thus sending it back to the Inquiry branch, or simply Cancel the request and ending the workflow.

Advertisements

Putting It All Together

Now that we have the workflow built out, we can take a look at how it all comes together and gives us that threaded comment view on our task forms and in the final email. I went ahead and submitted a request and document to be reviewed:

Once submitted, we receive the task to perform our review. For this scenario, we will ask for additional information and send it back to the original requester. You will notice that the All Responses section is blank because no comments have been added yet, that will change!

The original requester now has a task to respond to and plans to resubmit with some comments of their own. Here we see that the All Responses section is starting to have content.

Finally, we see that more comments are being added and the task has come back to the reviewer. At this point the process can go on and on as many times as required and all comments will be added to the workflow variable and then presented back onto the form and the final email.

Final Thoughts

Having threaded comments within a task form is a great way to see everything that has been done and said before this task without having to go to a bunch of other tools and find that information. While this example is simple, the approach for this can be applied to any size workflow. There are some things that I would do better here, such as cleaning up the date and time to make it more readable, and perhaps a better forms layout to make it easier to navigate. This will become important with larger forms. Let me know if this is something that you have done in your workflows or if you plan to use it in the future and how you are going to adapt it to your use cases. Until next time!

Where To Next?

It has been a bit quiet here lately and for good reason. I took some time and disconnected a bit to see where I wanted to take this and how I wanted to use my voice in this world (or this site specifically). While I started this site to blog about automation solutions using Nintex and all that Nintex has to offer, I felt that over time there was so much more that I wanted to discuss and dive into. I may be putting more work on myself here, but let’s share in the adventure!

Some Things Never Die

If you click on articles looking for insight into Nintex solutions, do not worry, I will still do write up solutions as I come across them. These usually spawn from other users that I am working with or from a use case that I am trying to prove out. In either case, I will still write those up and post there here. Where I want to expand on is the ideas and thoughts around automation as a whole, not always specific to Nintex. I have been working in automation for close to 10 years (lord I’m the “old guy” now) and have plenty of experience on the subject. I want to share that out as many people and organizations are in the midst of automation projects. Some are just starting out, some are trying to develop more mature systems and solutions, but in either case, I want to share my thoughts on the automation space more.

It Is All Fun and Games

Other areas I want to explore more when it comes to blog posts are my passion for gaming and my adventures with having 5 kids! Having 5 kids is a constant adventure. Sometimes it is easy and everything falls into place, but most of the time it is a crazy roller coaster that is minutes from flying off the rails. While most of this does not apply to those that read my posts, and I am by no means trying to give parenting advice, I want people to understand that we are all in this world living our best life and to try to enjoy that. Maybe it is more of a reminder for me, but you get my point!

I also play a lot of games….probably more than I should at my age, but it is my escape from reality. A chance to be something or someone I am not every single day. I chance to go on outlandish adventures with my friends and family and talk and laugh about it long after the game is over. There is a lot I would love to share about when it comes to gaming and perhaps over time it will spawn something else, but just like adding in other topics around automation, gaming is something I am very passionate about and plan to share.

Another piece that I want to explore, and is loosely tied to gaming, is leadership. If you know me, you have probably mention my goals and aspirations when it comes to leadership. While I am not looking to become the President, I do want to develop and refine my leadership skills, and I do so in some not-so-traditional ways. Everything from running a gaming community to coaching and managing baseball teams, I find unique ways to explore and hone leadership skills.

Let’s Be Serious

At the end of it all, I want to write about things that I am passionate about and what I want to share with you all. I know I am not writing to millions of followers…checks follower count…yep, I have 30, but I sharing these experiences and this content out is what I enjoy doing. I do not want to force myself to only write about one thing and I have found that when it feels forced, the quality of the content drops. For those looking for Nintex solutions, do not worry, I will continue to post those. For those waiting for the next adventure, strap in, it is going to be fun!

How To: Repeating Section Data to Excel with Nintex Workflow Cloud

Trying something different this time around and making a video walkthrough, so if you do not want to read, jump to the end and check out the video. I want to make more videos of these solution walkthrough and if you find them useful or helpful, let me know!

There are certainly multiple ways to approach this (and I will cover more in the future), but this approach will detail how to get repeating section data from a Nintex Workflow Cloud form into an existing Excel file using the Insert table data action. Let’s jump in! For this, I am going to keep it simple and have a form with just two (2) controls within my repeating section; first name and last name.

The Excel file I am going to push this data into is stored in my OneDrive and is already setup with a table (Table 1) that has two columns; first name and last name. As you can imagine, we are going to take the repeating data from the form and write it to the corresponding cells in our Excel file.

The actions required to get the data into Excel are only Loop for each and Insert table data. That’s it! So let’s breakdown each action and see how we get the data in proper cell.

Advertisements

First the Loop for each action. This is simple enough if you have worked with loops or data collections before, but what we are doing here is iterating through each item in our target collection, the repeating section in this scenario.

Second, the Insert table data action is where we will set where the data is going. For this action we will need to select our connection to the Excel file. For more information on how to create a connection, check out the Nintex help files. Once a connection has been made, you can select the file you want to write the data to, RepeatingSectionTemplate.xlsx is what I am using, and then select the table where the data is going. Assuming you are going to start inserting the data in the first row, we can use the loop index to help determine where the data goes each time we loop through it. If you are starting on a different row, you will need to offset the index variable by that number of rows.

Lastly, we will need to set the data points for each of the cells within the row. To do this, we select the first name and last name variables from the Current item within the Loop for each object when inserting our variables.

Advertisements

With everything in place, we can now push our repeating section data that we captured in the form into the Excel file. Here is a quick look at our end result:

As always, there are many ways to accomplish this, but with Nintex, creating a viable solution is easy and fast. Next time I will cover how to accomplish this using document generation and create a new Excel file each time rather than write into an existing one. Until next time!

Use Case: Go Back or Skip Stages Using Branch By Stage in Nintex Workflow Cloud

There are plenty of reasons why we would want to skip branches or even go back to a previous one in a Branch By Stage action within Nintex Workflow Cloud. Everything from approvals that need to go directly to an executive to scenarios where more data is required in order to move forward. What ever the reason, moving to the desired stage is easy to setup and can be done a variety of ways. This use case will walkthrough how to do so leveraging task forms and simple logic gates. Let’s dive in!

Scenario

For this one, we are going to look at a multi-level risk review process. This process has 4 different levels, but there are some business rules in place that will determine where and when to move to next. Risks can be Low, Med, High, or Critical, and follow a designated review path depending which level is selected. Here is a breakdown:

Level 1 – Review Risks: Low
Level 2 – Review Risks: Low – Medium
Level 3 – Review Risks: Medium – High
Level 4 – Review Risks: High – Critical

This means, for example, that a risk review that has been submitted as “High” skips to Level 3 automatically and then moves to Level 4. You’ll notice that each risk level requires at least 2 levels of review, this is by design. Another business rule that needs to be considered is that any review level has the ability to send it back to a previous level for reevaluation. Let’s take a look at how we can accomplish something like this above scenario using Nintex Workflow Cloud.

Advertisements

The Workflow

For this, I built out the full 4 level approval workflow, but I want to focus on the Low and Medium levels since we can extrapolate how to build the other branches from these. The form could be anything, but for the sake of our use case, there is a dropdown control that determines the “Risk Level” and we use that to drive where to start in our Branch by stage action.

If the form control evaluates as “Low”, it will start here, otherwise it will go to the proper branch. Starting off with the “Low” branch, we see that it is a simple task for someone to review. Here, there are only 2 outcomes that could happen; they Reject it and cancel the process, or they Approve it and moves onto the next branch, “Medium” in this case. Keep in mind that all reviews are 2 levels. Here is how we can achieve this within the workflow.

This is the most simple way to approach multi-stage approvals. Let’s add in some complexity such as what if the “Risk Level” starts at Medium or we need to provide a way for reviewers to send something back for more information. With these in mind, we can take a look at the “Medium” branch in our workflow.

Here we see the basics of the “Medium” risk level task are similar to the “Low” branch but with the additional outcome on the task for “Need More Info”. This allows for reviewers to select an outcome that does not move it forward to the next step nor cancel the process entirely.

You also might be noticing that we are using a “Branch by condition” here as well. This is because now that we are deeper into the process, we need to evaluate what the “Risk Level” is in order to decide where to do to next. In the scenario that the risk is “Low”, this review step is the second review and the process is completed, but if it is “Medium”, the process starts here and moves onto the proceeding branch (“High” in this case).

Advertisements

The same logic and approach can be used when building out the “Need More Info” branch. If the “Risk Level” is “Low” then we can move back to the “Low” branch in the workflow, however, if it is “Medium”, we simply move back to the “Medium” branch effectively re-issuing the task.

Looking back at our risk levels, we see that “Medium” starts at level 2, so how can we start the workflow in the proper branch? If you look at the “Branch by stage” action and how we configured it, we specify the “Initial Stage” by using the “Risk Level” control from our form. This means that whatever the control value is will determine what branch to go down first.

Advertisements

Taking it to the next level

For bonus points, I wanted to see how we could ensure that each review was 2 levels, even in the “Critical” branch. The way I approached this was to nest another task within the “Approve” branch and only go down that path if the “Risk Level” is “Critical”. Since this would be the second level review already for “High” level risks, we can simply exit the branch and move on with the rest of the workflow as needed.

Final Thoughts

There are many different ways to approach this problem within a workflow, but leveraging a State Machine, Branch by stage action in Nintex Workflow Cloud, helps make it easy to build a solution around and easy to understand. You’ll notice that each branch in the action has a “Change stage” action and this is for good reason. Each branch is really just a loop and the “Change stage” action tells the loop where to go to next when it gets to the end. Without that action, you could imagine, the branch would continue to loop!

How are you using the Branch by stage action? Are there other ways that you would have solved this business process?

There & Back Again: Google to Microsoft with Nintex Workflow Cloud

When it comes to Nintex workflow, many times the first thought is “Microsoft”. And while this is certainly still common, there has always been the ability to go a different direction when leveraging the power of the Nintex platform, especially Nintex Workflow Cloud. Within Nintex Workflow Cloud there are a multitude of connectors ranging from AccuWeather to Zendesk and an Xtensions framework that allows users to create their own workflow actions. This paves the way for processes to be built and optimized for with the current systems in mind without the need for complex workarounds or changing the process to fit the tool. For myself, a lot of times I simply frame this as the ability to change platforms or systems without having to rebuild the entire process. Let’s explore this idea more, but specifically around Google and Microsoft.

The Story Thus Far

I recently worked with an organization (Company A) that was going through some growth via acquisitions and had to consolidate systems, platforms, people, and processes. In the middle of all of this, Nintex Workflow Cloud was the way that the majority of their processes were being automated and how data was getting to the correct people and systems. Things like on-boarding new employees (which they would be using a lot of given the acquisition), contract and content management, and other various back-office processes connecting to legacy applications. These processes leveraged a variety of platforms but many times Microsoft was at the center of it. Whether it was SharePoint Online, Excel, Word, OneDrive, or even just posting content to Teams, Microsoft products were used to facilitate processes a lot. On the other hand, the acquired organization (we’ll call them Company G), used the G-Suite. This was how many things were advanced through their processes without the luxury of Nintex Workflow Cloud. The immediate response was to migrate all the new content and process from Google into Microsoft since there was already more being done with Microsoft within Company A; but was this the right approach? How much re-work was required taking this approach? These were the questions they needed to stop and evaluate before making decisions. This is where a simple approach changed all future decisions.

When Company A began to evaluate and catalog the processes that they were acquiring, they quickly realized that many of them were quite similar. Capturing data via forms and then pushing that data into the proper systems for retention. The key differences were where the data resided and the complexity of the tools that orchestrated the automation. Many times, they found that once the data moved to the new system in the process, that system would be leveraged to continue the flow of work. Things like notifications and tasks were commonplace, but each different depending on the system that it came from. This led to confusion for employees as they did not know where to go to complete their work. External participants faced similar issues; the notifications they were provided to complete essential steps in their processes were not standardized or streamlined.

Advertisements

With the power of Nintex Workflow Cloud, the Company quickly saw the potential to consolidate processes all under one workflow platform but still allow for the data to flow to the proper systems. This was as simple as adding a connection within Nintex Workflow Cloud and then adding the necessary actions in the right place. An example of this was when their templates had to be used for Document Generation, depending on where the template resided, it could be pulled in and used in the workflow.

In the above screenshot, we see how easy it is to add two actions to replicate what is already being done but pointing to where the content already is. In this case, the is a need to grab logo images and the document template to be used in the document generation action. Another example of this that came up was having the notification come from different systems. In this case, there was a need to have meetings set using Google Calendar or Microsoft Exchange depending on the business needs. Using a simple branch action within Nintex Workflow Cloud, we can easily achieve something like this:

Advertisements

Final Thoughts

When it comes to consolidating automation, there is a lot of consider and ultimately ensuring that the processes continue to run is paramount to all else. This means that while some parts need to be re-architected, merged into another processes, or down-right deprecated, the first concern should always be continuing execution of the processes. With Nintex Workflow Cloud, we can easily achieve this by dragging actions around to rearrange the flow of the process. We can also add in a multitude of different connectors so that the data gets to (or is pulled from) the proper system. We remove the system dependency and open a world of opportunity when it comes to process automation.

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.

Advertisements

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.

GetExcelWorkbookID Download

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.

Advertisements

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.

Advertisements

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.

Advertisements

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 https://www.w3schools.com/html/html_tables.asp 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>
<html>
<head>
<style>
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;
}
</style>
</head>
<body>

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.

‍‍table_rows‍
<tr>
<td>‍[[First Name‍]]</td>
<td>‍[[Last Name‍]]</td>
<td>‍[[Email‍]]</td>
</tr>

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.

Advertisements

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:

‍‍table_css‍
<table>
<tr>
<th>First Name</th>
<th>Last Name</th>
<th>Email Address</th>
</tr>
‍‍table_rows‍
</table>
</body>
</html>

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.

Advertisements

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.

JotBlocks

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.

Advertisements

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.

Advertisements

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:

{{!##{PropertyName:"Value"}##!}}

{{!##{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:

{{!##{ 
Name:"EmployeeInitials",
InputType:"Signatory",
FieldType:"Written",
Border:"All",
InkColor:"Black",
Instructions:"Please use the mouse to write your initials.",
Height:"0.05",
Width:"0.15",
SignatureType:"Initials",
SignatoryEmail:"<<StartEvent_email_address_r16lUR8uTMm>>"
}##!}}

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:

Advertisements

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.

Advertisements

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.