You were referencing to the built in Related Items column that links tasks to list items. This is handled automatically.

But what do you need on the web part page to display? All of the tasks related to an Item? or all related to a list?

Andrew, thanks for the feedback. However, the "Nintex Workflow Multi Outcome Task" content type I'm using in the task list doesn't provide the list item's ID in the Related Items column - so one can't connect to it from the parent list on a web part page. The Related Content column in the task list does retain the link to the Title column in the parent list - but it still is unable to connect to anything in the parent list.

My list workflow that calls the Flexitask does write to a RequestID column to store the parent items ID - but this doesn't happen when the task is created - only after its been responded to in some way.

I really need the two connected in some way when the task is created.

I apologize I didn't provide any further feedback, but I accomplished a similar goal, to put extra meta data on the workflow task item, by creating an event receiver on the workflow task list. It would fetch the necessary data and add it to a custom content type that is an extension of the nintex workflow task - multi outcome content type. I would avoid starting a workflow on the task itself, as this causes locking issues.

Andrew, thanks for the feedback. I had a feeling it was going to require something on this level. Unfortunately I'm not sure I can justify outside resources for this. Your solution did give me a couple of ideas to try.

One attempt was to get the requesting item's ID from the Related Content column by using a calculated column. The following formula looked like it would handle it: =RIGHT([Related Content],LEN([Related Content])-FIND("=",[Related Content]))

Unfortunately, the Related Content column is not allowed or accessible from the calculated column - typical!

The other method I'm going to try is to set the default value for the task list's RecordID column prior to creating the task. That way when the task is created it will set the RecordID field with the requesting item's ID - which is precisely what I'm looking for. If this is done by each request, then there shouldn't be an issue with a task getting the wrong reference ID.

I'll post back if I get this method working.

Andrew, fyi - I was able to successfully set the default value for the task item's RequestID text field using a PowerShell script and the PowerActivity action from DataOne (that runs scripts from Nintex workflows). The script sets the default value for the RequestID before the flexi-task action is run. Once the task is created it gets the default value previously assigned to the RequestID field.

This RequestID value is now available (while the task is still pending) and is related to the requesting employee list on a web part page. The relationship is the Employee list items' ID column and the task lists RequestID column.

Thanks again for the collaboration.

Here's the PowerShell script for reference:

Add-PSSnapin Microsoft.SharePoint.PowerShell
$global:var1 = "{WorkflowVariable:txtItemID}"

[Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges(
  {
    #Get SPSite & SPWeb
      $colSite=Get-SPSite "http://myIntranet.col/fa"
      $rootWeb = $colSite.RootWeb
      $projWeb = Get-SPWeb -Identity "http://myIntranet.col/fa"

    # Set List & field to update
      $taskList = $projWeb.Lists "OnBoarding Tasks"]
      $defaultField = $taskList.Fields$"RequestID"]
      $defaultField.defaultvalue = $global:var1
      $defaultField.Update()
      $taskList.Update()

    # Wait 1 seconds to continue into next section
      oSystem.Threading.Thread]::Sleep(1000)

      $projWeb.Dispose()
      $colSite.Dispose()
  }
)

Great job Gerard finding this solution!

So you are setting the RequestID field of the task list to the value of the CurrentItem ID? Is that what the value of txtLoopName would be?

I found myself having to use runwithelevated also when running powershell commands. I don't think you need to fetch the site and root web object though. I've also been successful setting local scope variables within the runwithelevated that are values of workflow variables. I preferred this over global scope variables.

Also, using the quotes around the brackets of a workflow variable worked just fine for me as it did for you. But there are times I use {TextStart}{TextEnd} if I am expecting unique characters that could be a concern for encoding.

Andrew, correct - regarding the current item's ID - except my older script had the wrong variable (txtLoopName) so I changed it here to the correct one (txtItemID).

Yeh, the site and root objects are probably overkill - just my typical cautious approach. I also agree on the local vs global vars. However, I did find that there could be issues with using local scope variable for the $var1, ... $var10 variables that PowerActivity action allows to pass between the workflow action and PowerShell. They suggested globals for these cases. In their action I then pass these globals off to other workflow variables for subsequent tracking/recording.

The use of quotes was a trial/error thing. I noticed that varying powershell commands require strings imbedded in double quotes, others with strings in brackets. The problem for me was sorting out how the PowerActivity parses these. Throw in the workflow variables and that complicates it further. Since I'm after consistency, I find that setting the workflow variables to global:vars first, then using the global vars throughout the script simplifies the reading and reduces errors.

Regards

Great information. So are you able to use the global var from one instance of the action to the other? I was wondering what its lifespan would be, whether there would be new shell scopes.

Andrew, the Global reference here may misleading in how its applied. It appears to be global only in the sense that the variable is accessible between the workflow and the current PowerActivity (PowerShell) action. Values can be passed back and forth within the context of the current PowerActivity/Powershell session. As you suspected the lifespan of each PowerActivity and the PowerShell it runs is distinct in scope and is a separate session. I tested the access of these global vars across actions and found that they did not bridge the shell sessions.

Regards