02 July 2010

How to get the delegated user of a task

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.
OBS: The approach described here don't works for direct task delegation on the action, it just works if the user delegates all of his tasks. A good example of how to handle a directly delegated task can be found here:

Below the workflow is explained step by step.

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/

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, and and here is available the Workflow file. I hope it is useful!


  1. Hello Vadim! Thank you for the feedback. I hope my posts can help the Nintex Developers/Designers :)

  2. Hello Pilan, could you share a copy of the workflow. The image of the workflow is difficult to see and this seems like the perfect solution to resolve a similar problem of mine.


  3. Hello Lance

    The workflow link is available here:

    I hope it's useful!

    best regards

  4. Very nice suggestion,
    What would you do if u have like 100 running workflows, each with about 5 approvers in state machine? If every task will be paralel with cycle like u mentioned, Timer job is not going to thank you. Every of the 100 WF will every 5 minutes refresh cycle for the state delegated or not. If someone delegate, same thing will happen on the next approver. This happens every 5 minutes. In my opinion you will stuck your timer and nothing will work in workflow, or very slowly. Now thing about 100 new workflows a day, it's hardly usable for productional enviroment, but nice suggestion like I said.




  5. Wow! Great post! The content is very rich, and I really like it.

    Server 2016
    Microsoft Server 2016 Support