Skip to main content

I am working on a complicated process that requires many different types of approvals and data requests.  All these tasks are created in a task list.  I would like to supply a value (Job Number) to the task list so we can create grouping views on the tasks in the task list so managers can monitor who has completed their tasks and who hasn't.  I have searched for instructions on how to supply this value to a task.  I have created an extra field in the task Content Type and thus the task list, but I can't find a way to populate that field from the list workflow.  

 

Has anyone done something like this before.  We are still using Nintex 2013 for a 2013 on-prem farm but this will be migrated to 2019 soon.

Hi,

Has this job number a regular structure?? I mean, depend from the task status or another variable??

If I'm understanding correctly, what you'd like to do is to populate a Task List Item with *some* information from its associated List Item.

So, if you have a Job List Item that creates a "Job Task Item", you want the JobNumber column from the Job List Item to be pushed over to the Job Task Item.

Is that correct? 


Yes.  The whole process has a unique number (Request Number) and so I would like put that value in each task list item, so we can create views in the task list by Request Number.  I have attempted to modify the Content Type, but I can't find anything in Nintex that will allow me to write that value to the assigned tasks. 


Alright. I had to do something similar in my own situation and was only ever to find one reliable method of making it happen. It is NOT particularly conventional and probably goes against a few Workflow Best Practices, but it gets results and that's all that matters. I did a lot of testing with this to see if there was another way to do it, but couldn't find a better or working solution, so, without further blabbering on my part, here a setup for the workflow: Populate Task Info From Item



 



I have a test list called Self Lookup List





 



The Column [PRD Tag Number] is a Unique single line text column, and the [Fluid Name] column is a non-unique single line text column. 



 



As for the Task List, I created one called Test Task List: 





 



As you can see, I've created both of the columns that I'd like to pull from my regular List, over here on the Task List as well. 



 



(Note: BE CAREFUL! When you are creating your columns on the Task List (or using an existing Site Column), make sure that you do not set the column to enforce unique values If there is even a slight chance that a second task could be created that will *also* need information from an item that is has already been processed in the past, otherwise, you're going to have a bad day! Remember that you can have multiple tasks associated back to the same item!)



 



Now that we have our lists, create a new workflow on the Test Task List.



 



Feel free to, at this point, Import the attached workflow "PUBLIC-VERSION_Populate_Task_Info_From_Item.nwf"





 



The Workflow: 



 



There only 7 actions (8 if you count the Action Set) in the version I'm uploading but you can add more if you need to do further processing on any of the data you get back from the List Item associated to the Task Item. The basic idea is that we want to get the value of an Item Properties called Workflow Item ID. However, because of some initiation silliness, the workflow for a Task Item can start before Workflow Item ID has actually been handed the value of the ID of List Item that the Task Item should be associated with! This means that if we just try to use that value too early, it results in *nothing happening* which isn't useful. Because of that, we'll need to make a loop that will constantly try to use the value it gets from the Item Property reference, and if it succeeds then it uses that value to grab more information from the List Item in question or it just loops up to a max threshold of times before giving up.



 



Below is a breakdown of the Actions and Configuration. 



 



Let's start with... start conditions. Most important are highlighted. Everything is your choice





 



The Variables





 



Default Variable Values



 



var_LoopThreshold = 0



var_LoopTrigger = 0



var_TaskListSite = http://SharePointURL/sites/MainSite/SubSite (change this to your Task List Site)



var_ErrorCaught = No



 



The Actions and How They Work



 



1. Loop (NOT for each!)





 



Loop Configuration:





 



Both var_LoopTrigger and var_LoopThreshold are set to 0 by default. With only this information and loop configuration, the loop would loop 100 times before stopping which prevents it from endlessly cycling in the event that *something* terrible happens. 



 



2. Set Variable





 



Set Variable Configuration: 





 



Here we just set the var_AssociatedListItemID to the current (Task) Item's - Workflow Item ID (that is the value of the ID that is associated to this Task).



 



3. Query List





 



Configuration





 



Configuration Continued: 





 



CAML Query Code: 



 



<Query>

<Lists>

<List Title="Self Lookup List" />

</Lists>

<ViewFields>

<FieldRef Name="PRD_x0020_Tag_x0020_Number" />

<FieldRef Name="Fluid_x0020_Name" />

<FieldRef Name="ID" />

</ViewFields>

<Where>

<Eq>

<FieldRef Name="ID" />

<Value Type="Number">{WorkflowVariable:var_AssociatedListItemID}</Value>

</Eq>

</Where>

</Query>


 



 



So all we're doing is trying to use whatever List Item ID we stored in our variable from the action just before this. This is also where we pull any information from the List Item we'd like to get the info from. In this case I'm grabbing the PRD Tag Number, Fluid Name, and also the ID.



 



You can see in the second picture where I'm assigning a variable to each value returned. You may notice that I'm using the {var_LoopTrigger} variable and assigning it the value of the returned ID from our associated Item. I'm doing this as it should work as a sort of "short circuit" for the Loop. Remember, the loop will continue to go if it hasn't looped over 100 times AND the var_LoopTrigger is lesser than 1. Because IDs in SharePoint cannot be below the value of 1, if our query succeeded, then our var_LoopTrigger will now be greater than 0, which will let our Loop know that it can stop looping!



 



 



4. Math Operation





 



Configuration





 



This is how we increment our Loop Threshold variable up by one for each loop towards it's max value of 100 (at which point the loop will stop).



 



5. Update Multiple Items





 



 Configuration





 



Configuration Continued





 



This is where you'll actually update the Task Item. You may be wondering why I didn't just use "Update Item" action, however, for whatever reason I could never get that to actually work consistently. You'll see that the two columns I want to populate ([PRD Tag Number], and [Fluid Name]) are both listed as Fields to update. 



 



Additionally I have opted to Capture Errors in the event something goes wrong. If our Loop stops after 100 tries and doesn't ever find an Associated List Item ID, when this runs it should also produce an Error that you / I might wanna see. This will see to it that we will get an email!



 



 



6. Run If





 



Configuration





 



If we do catch an error, then we can drop everything we'd like to do inside of the Run If action.



 



7. Send Notification





 



Configuration





 



Remember to populate the "To" field with a real email address! This will send you an email if this workflow ever runs into a wall. 



 



 



----------



 



And with this workflow setup to run any time a new Task List Item is created, it should automatically populate each new task with the fields you've specified to get populated here in this workflow: 





 



I hope this helps you to achieve what you'd like it to. 



 


Reply