Hi, thank you for your reply. Could you please elaborate on your answer?

I have LineItems smartobject, joined to ProductLines smartobject which has a field that contains a Role group name.
For example, there may be 10 LineItems on a form that are joined to 6 distinct ProductLines which have only 4 distinct Role groups.
I would like to have only 4 tasks assigned either thru sub workflows or 1 task assigned to 4 distinct Role groups in a consensus.

Thanks in advance!

Dynamic roles can be configured in the following way:

This article has more detail on it https://help.nintex.com/en-US/k2cloud/userguide/current/default.htm#K2-Workflow-Designer/Common/DynamicUser/DynamicUser.htm?Highlight=dynamic%20roles

Cheers

Thank you paulk for your response. 

I think this might work for small number of possible roles. It may not work for my case as there are 15+ Role groups right now (and will grow in the future).. And the number of combinations may not be feasible to code in rules?? 

As you have access to the database could you push the logic to get a list of roles that need to approve for a given order into a stored procedure?

You could then use a SmartIbject call and the for each activity to then launch a separate process for each resolved role.

You can then choose to either wait for those approvals to complete before continuing on or just going on after they have launched.

Cheers

I'm using K2 Cloud.. might I be able to do this if I used OPDA and an on-premise database?

Right now, I'm calling subworkflow for each LineItem.. and that's not efficient as some Role groups might get multiple tasks for the same request.

Similar to your directions and using only cloud smartobjects, might I:

1. Create a smartobject to store requestID, RoleGroupName

2. Get the list of Roles required for the approval of a request

3. Loop thru the list and save requestID, RoleGroupName to smartobject in step 1.. (this is to de-duplicate and create distinct RoleGroupName per requestID)

4. Get the RoleGroupNames for requestID and store in this distinct list

5. Call subworkflow now for each of the  RoleGroupName in step 4

?

Ahh yes of course. Sorry wrong set up

You could also at the point you start the sub workflow set a flag to say that role has already got a process running. That way when you start a new one for that same role you could query that value in the start rule and don't start one for that role.

Cheers