Hello guys! I originally wrote this post at my blog, but I also would like to share it here on the forum as well.
The current build of the nintex workflow 2007 (11004) isn't capable to get the delegated person by itself. Explaining better this scenario, the idea is to know when a User Task (e.g.: Flexi Task or Approval) is sent to a specific user, but this user have delegated all of his tasks using the task delegation from Nintex.
After searching for many days for a solution, I found a way to solve the problem. On this post I will show how is possible to get the user name of a delegated user. But one question before I start: Why do I need that? Well in my case, I needed the user name for 2 reasons:
- Update a list collum with the name of the user who handled the task;
- Give this user permissions on the List Item;
In my scenario, I was blocking the permissions for specific users, as a requirement of the Workflow. In order to give the delegated users correct permissions to view or modify the List Item, because for the workflow, just the original approver have permission, not the delegated. Just to clarify, I'm not talking about the task itself, the delegated user for who the task is assigned, get the permission to the task automatically from the workflow.
1. A new List was created, with the name "Delegation Test" and added a new colunm "Person" of the type "Person or Group".
2. The workflow is quite simple, I only have a FlexiTask which is assigned to the initiator. To make the scenario more real, I removed the permissions of all users and give just permissions to the initiator.
3. Before continuing, It's necessary to setup a variable to use later. It's a variable to store the Initiator User name. I gave the name "initiatorFullUserName". This variable is necessary because Nintex don't allow to use Common lookups in Comparison Actions.
4. The Flexi task must run in parallel with the Action Set used to get the delegated user. It' s necessary because we need to get the delegated user after the task is assigned to him. Approving or reject just send the Initiator a message.
5. Now we really will work with the delegation part. In order to get the delegated user, we will use the Nintex Workflow Web Service, available in every SharePoint site (e.g.: http://mysite/_vti_bin/nintexworkflow/workflow.asmx
To handle this, we will invoke the "GetRunningWorkflowTasksForListItem" Method. For who are not used to the Nintex and Sharepoint Web Services, I will make a post in the future specifically for this topic, but now, I will only explain this method.
6. In order to configure the action, we need to provide some parameters, "List Name" and "ID" of the Item, all available as lookup data on the workflow, in "Commom" and "Item Properties" respectively. In order to store the results of the Web Service call (we need it to get the delegated user) I created a text variable, called "wsresult". It's also important to select the result format as "Xml", in order to insert a <xml>
tag on the result.
7. Here is a important step: On the XSL Transform textbox, we can create a Xpath query to filter the result. Bellow is the XSLT used for our example. Using it, we get exactly the user name of the person for who the task is assigned. I will not explain how the XSLT works in details because it's not the point here, but I recommend a website for who wants to study it: http://www.w3schools.com/xsl/
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
8. The last configuration of this action is to Capture the errors. We need to do it, because errors will happen! Yes can sound a little bit strange, but when we run the FlexiTask and the Web Service call in parallel, the webservice always runs first, and the task is not assigned. In order to avoid a workflow error, we capture
the error and keep the task running until there is no user name on the variable wsresult, using a "Loop" action. I have defined the variable wsresult as "string.empty" before the WebService call, to avoid a possible errors using a real empty string.
9. When the Workflow leave this Loop Action, it will have the name of the user for who the task is assigned. Now, we need to check if the username returned by the workflow is the same of the user assigned to the task (in our case, the initiator). If it's a different user name, it means the task is delegated!
10. Now, having the username, it's possible to do anything with the workflow, depending on the requirements. In my case, I will give the delegated user view permissions on the item, and will update the list adding the name of the delegated user to the "Person" field.
11. Bellow I will post the full workflow image. I hope it is useful!