Display related item repeating section in Nintex Workflow task form

Last week I worked with a customer that had repeating sections in Nintex Forms 2013 item form and Nintex Workflow 2013 workflow associated with the list. The customer had the requirement to be able to properly display the repeating section data in the workflow task forms. This requirement does not seems to be a straightforward to accomplish, but in this post I am going to demonstration that this is actually very simple and since I haven't found this in other sources I am sharing my solution and other useful links in this post.

The issue with the repeating section is that it is living as "section"only in the form. You can connect the entire repeating section to a field with type "Multiple lines of text" and you will see that our repeating section value is actually saved as XML.

The item actually looks like this:

The first nice thing that is not directly related to the title of this post is to make the XML data looks better in List View. To accomplish this I am going to use the CSR (Client-side rendering) approach demonstrated in this post "Displaying Repeating Section as table in List View - the CSR approach". Adapting and applying the script to my list view gives me below result that is way better than the XML.

The way to make sense out of the repeating section in workflow is by querying the XML from the field. I will not go in dept since there are many resource on the subject. One thing that can help you in this task is this article "Nintex Forms/Workflow - Parsing Repeating Section Data" by Vadim Tabakman.

Now to the reason to write this post. If you have tasks in your workflow it will not be unusual you or your customer/users to want to see the related item properties right in the task form instead clicking on links. If you leave the form as it is, the best you can get is to view the repeating section as XML. You can edit the task forms with Nintex Forms for most of the task templates you will get a good starting point and all item properties controls will be created. However check out how this controls look like in three common tasks. From left to right Flexi Task, Request review and Request data.

As you can see the data from the repeating section is displayed as XML. Even in the "Request data" template where I have used "List item" control to display the related item. 

This was also the case with the customer, they had many "Request data" tasks and all of them were using "List item" control to display the related item.

The solution to this is very simple, just create a new repeating section in the task form, recreate all child controls by replicating the data type and the Name of the controls. Then connect the repeating section control to the related item field that contains the XML from the related item. Checkout how a Flexi task looks like if you recreate the repeating section as described.

The data from the repeating section in the related item is represented as repeating section in the task form as well. Just make sure that the names of the controls are as in the original item, make the repeating section read only in the task form and you will be completely fine.

I tested the same approach in SharePoint 2016 and Office 365. However something interesting is happening with the XML as you can see in the screenshot below (the field is called Rep)

The important thing is that the repeating section is visualized as expected. If I found what is happening with the XML might blog about it.

I hope that this was helpful! 

Pause a Nintex workflow for less than 5 minutes in SharePoint Server and Office 365

Last week I spent almost 2 days fixing a complex Nintex/SharePoint 2013 issue with one of our customers. The customer was not very big in terms of headcount, but they were using Nintex workflow to automate all sorts of processes(one of the biggest I have worked with).
There were Workflow timer jobs stucking/failing, workflows exiting with errors for no obvious reason and more. The issue was resolved with a couple of fixes and at least the workflows were executed when they should and were ending as they were designed to.
Some of the issues and improvement points I flagged were: not properly scaled Nintex deployment, incorrect service topology, outdated product versions and poor workflow design.
Now, the fourth (poor workflow design) was partially dictated by the inadequate scale of the deployment. They were using a lot Pause and Commit pending changes actions. Many of the workflows were designed to have two minute pause after the first couple of actions.
As maybe you know the pause action actually pauses the workflow instance for the defined period of time, but the workflow will not resume immediately, it will be resumed when the "Workflow" Timer Job is executed. The default schedule of this job is every 5 minutes. This means that you cannot pause a workflow for less than 5 minutes or pause it for exactly the time you have set. You can change the schedule of the Workflow timer job to workaround the first limitation, but this can put additional load on your system.
This is why I demonstrated an alternative of the Pause action that do not pause the workflow instance, but just waits a certain amount of time before continuing the execution. I have not seen this approach in other sources and this is why I decided to share and explain it in this post.
There is another alternative to pause a workflow for less than 5 minutes. It is described in this article.
As you can see this alternative requires "NTX PowerShell Action". This is great, but this action is open source, it is deployed with Farm solution and although developed and published by Nintex Employee this addon is not backed and supported by Nintex. The PowerShell action is fantastic, but in my opinion it is not worth to deploy it just to use it as Pause alternative. Also you cannot use it in Office 365(SharePoint Online).
The PowerShell example works by executing the powershell code that will just wait a certain amount of time, then it will continue the execution. Obviously to pause a workflow we need to do some sort of waiting. There is no out of the box action that just waits, as we know Pause action is not doing anything, but actually idling the instance execution at certain point and waits for the timer job to resume it after the time is elapsed. With the powershell example we use the powershell (.Net) framework to achieve wating without doing anything for certain time. The same thing can be achieved with T-SQL statement execution and in Nintex Workflow both On-Prem. and Office 365 we have "Execute SQL" action.
If we want to put a wait in our SQL query for two minutes we can use the code below:

---

WAITFOR DELAY '00:02'

---

I am not a SQL guy and was surprised to find out that this statement works outside of the SQL Management tools.
Below is the designer look of my demo workflow in SharePoint 2013. This should also work for SharePoint/Nintex 2010.

As you can see it is pretty simple just for PoC. Below is the configuration of the "Execute SQL" action.

I am using a connection string that is using "SQL" as server, this is alias to the SQL instance that hosts my SharePoint, I am using SSPI security with Windows credential that are actually my farm account saved as global constant.
Below are the details from the execution. You can see that Execute SQL actions took exactly 2 minutes to complete.

Unfortunately you cannot use this approach on-premise  for pauses longer than 5 minutes without doing a loop and in this loop execute multiple times delays that are less than 5 minutes. If you do set delay more than 5 minutes the workflow will fail with error "Error performing database operation. Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding." even if you set connection timeout in the connection string to be more than the 5 minute delay. I will do some more tests/research and might report this as bug.

As described in the MSDN documentation of the WAITFOR statement, it should work against Azure SQL Database. In Nintex workflow for Office 365 we also have Execute SQL action. I actually tested this and noticed two things, the connection timeout you specified in the connection string will be set to 365 if the number is bigger than that, also if you set a delay longer than 4 minutes you will get some unexpected http errors during the execution, the workflow manager will do a couple of retries and then it will fail. I think that both are issues with the Workflow Manager in SharePoint Online.
This is not so important because the Pause action in the SharePoint 2013 workflows (Workflow Manager) are not depending on SharePoint timer jobs and you will not get the same pause issues as in on-premise 2010 framework, but it is still an option. See example configuration of the action below.

My final words are that this might be extremely useful if you need to put some short pauses(not more than 5 min.) in your on-premise workflows. I hope you find this useful!

Error when access Nintex Live Management page on fresh Nintex Workflow 2013 installation.[Tip]

Today I hit a strange issue with a fresh installation of Nintex Workflow 2013 with Nintex Live.
Nintex Live solution was deployed by the installer. However when I tried to access the Nintex Live Management page in the Central Administration I received below error.

---

The resource object with key 'LiveAdmin_Page_Management_Title' was not found.

---

If you have done everything correctly so far the solution is very simple.
Open SharePoint Management Shell as Administrator and launch the command Install-LiveService , test if the page is now available, perform IISRESET on your CA server(s).

Move away from the Workflow Tasks with Nintex for Office 365

In this post I am going to demonstrate my solution for a requirement that I believe is not an exception.

It is a fact that users not always like the workflow tasks. In the last two weeks I received this requirement twice. The first requirement was around an internal project I am working on in O365 with Nintex Forms and Nintex Workflow and the second came from a customer with SharePoint Server 2010, Nintex Workflow and InfoPath forms that wanted to get rid of the tasks in their Business Travel approval process. The managers that are approving those business travel requests just did not liked to receive a mail with a link to a task where to select Approve/Reject and if they want to see what actually they are approving to click on a second link and then go back to the task to complete it. They wanted to do everything in the InfoPath form where they can see all the numbers and can directly approve or reject. Of course from the title it is clear that I will focus on the first scenario in O365 with Nintex Workflow and Forms. 

Since the scenario is in SharePoint Online things are working a bit different, I will show you some key bits in Nintex for O365 that can help you(I hope) to meet the requirement to automate a process without using workflow tasks.

For demo purposes I am going to use a basic leave request form. The user will create a new item and submit it, then the person pointed as Approver should approve the request just by clicking a button in the form. See how the initial form looks like below.

One of the key things is that our approval workflow should know in what stage the form currently is.

The workflow can wait for item field change, a Status drop-down field is an option, but let's say you have many stages of approval, like Team Lead approval, HR approval and so on. In more complex workflows this will be confusing for the users and in general it will not be a good idea to let the users choose what is the stage of the process.

This is why we are going to make different buttons that will be visible/active in the different stages for different users and on click the buttons will set value of a text Status field.

In our example if the form is new the submit button will save the form and will set status "New", if the status is New the workflow will send a mail to the approver inviting him to review the request, it will also set some status for example Awaiting Approval. If the status is "Awaiting Approval" a different set of buttons Approve/Reject will be shown and they will set the status accordingly when they are clicked.
The first thing to setup will be the initial SUBMIT and CANCEL buttons, the submit button will save the form and will change the status to "New". This buttons will be visible only when the form is new and the Status field is empty.
The button controls in Nintex Forms for O365 have a nice feature, you can connect them to a field so when they are clicked they will send some value to that field. In our case we are going to send a string "New" to field Status. Below you can see how this button control setting looks like, everything is located under Advanced.

The next thing to do for both controls is to set an Expression for the setting that defines the visibility of the control, when the expression returns true the control will be visible, when false the control will be hidden. We are doing this for both buttons because if we leave the form with only one Cancel button in all stages the button will be placed only in one place, and other functional Submit buttons will be placed below or above it(I guess that this can be fixed with some CSS, but this is not a subject now). The expression is very simple, we are going to use Inline Function IsNullOrEmpty for Item Property(field) Status, this setting is located under Appearance, Visible and in the drop-down choose Expression. If the field is empty the function will return true and the button will be visible.

The story for the Approve/Reject is basically the same, they will be Save and Submit button controls connected to the Status field, that will set values Approved or Rejected, however we will need them to be visible when the status is "Awaiting Approval".
Also the Approve/Reject buttons should be visible only for the user that has the authority to approve or reject the  Leave request. This is not a difficult task to achieve, in our case the person that should approve the request is given in field Approver that is from type Person/Group.
Here comes another great feature, we can reference Current User Display Name,Email and Login ID in the form out of the box, we also can get this values from Person field in the current item.
So what we need to do is to set our Visible expression to be true when the Status is equal to "Awaiting Approval" and the email(for example) of the current user is equal to the Approver's email.
Entire logic is done by using the "And" Inline Function, for values we are going to use the function Equals for both conditions. This way the Approve/Reject buttons will be available only in "Awaiting Approval" stage for the appropriate user.

You can see how both forms look like in Edit mode side by side below. The left view is what the Approver will see with the options to Approve/Reject and on the right is a regular user that cannot even Save the form, there is no submit button in the form or Save in the ribbon.

Here comes the part where we will need to create the Approval Workflow for our Leave Requests.
As already mentioned the workflow will need to set the Status field to "Awaiting Approval" so we can activate the Approve/Reject buttons, nothing special about that, we will do it with action "Set Field in Current Item".
After we have done this we should make the workflow to wait for Status field change. We can use "Wait for Field Change in Current Item" action. There is one blocking point with this approach if we use this action alone and it is that this action will wait for field change only to a single predefined value, but we have two possible values Approved or Rejected.
This is why we are going to use the Parallel Block action. This action can execute many action branches simultaneously. We can have one branch where to wait for Rejected and one to wait for Approved. This action in Office 365 also has a feature that's making this logic possible. We can have two condition  for exit from the parallel block.
One of the condition is always end of one of the branches and second one is a variable that should evaluate to True. This is so important because without it the parallel block will wait until all branches are finished and the branch where we wait for Status to change to Rejected will never end if the item was Approved.
This is why we create a variable from type Boolean and assign value "No" just right before the Parallel Block(Not sure if this is absolutely needed but just to be on the save side). Then we set this variable as "Completion Condition"(in the action settings) for the Block and after every action for waiting field change we set this variable to True("Yes"), this way we are going to exit from the block when individual branch finish. Before the exit from each branch you can do State Machine State Change or something else, it depends on how you have designed your workflow and how complex is the process. See how this step looks like below.

If you are wondering what is the third branch for, it is for a reminder using a Loop with Condition action. We are going to pause the branch execution for a period of time let's say 1 day after this the workflow will send a reminder that there is pending Leave Request that requires approval and this will repeat until we exit the Condition Loop or the Parallel block. We need some condition for the loop, this is why we are going to put the variable that we use for completion of the entire branch.

This became one long post, I hope that I have not bored you to death, maybe this topic was more suitable for video tutorial. I hope that this was helpful, happy Nintexing!