I assign a first flexi task to a GROUP. When the task is approved, I would like to assign a second task to the same group EXCEPT the person who approved the first task.
How can this be accomplished ?
Assign flexi task to group except last approver
+1
if you can change group membership, you can remove last approver from the group. here is described an UDA how to do that Remove user from SharePoint group - UDA
+8Hi Gianluca,
I believe it might be difficult if you try to edit group membership as when you have multiple workflows running (on different list items) it might make the group membership unstable.
Other way I could think of is you would have to do some processing in your own workflow. I havent tried this but can give you a little overview.
1] Create a variable (people multi) and set the default value to the value of the group.
2] Extract all the users from the group and store it in any collection variable
Use this as an example - How to Get All the Users From a Specific SharePoint Group Using NINTEX Workflow
3] After your flexi task has been actioned by the person, get the "last task respondent" and loop through the list of users you have got in step 2 above and remove the particular user from the collection.
4] Assign the task to the remaining people in the collection.
I have tried this but the approach should work, you would have to play around with variable types that best suits your needs.
Regards,
Shrini
+1Unfortunately this is not an option for me as this would affect other workflow instances that might be running at the same time assigning tasks to the same group...
Instance 1 : Assign Task to Group. U1 approves. U1 is removed from Group. Assign Task to Group.
Instance 2 : Assign Task to Group (<-- U1 is missing now)
ok, I see (and moreless expected that)
one another idea might be:
- this requires that you 'create individual taks for every group member'
- let the flexi task store all the created task IDs into a collection variable
- once your task is completed, iterate through this collection and for every single task ID query for 'AssignedTo' column from Task list
- store all the assignees but 'last approver' to a variable and use the variable for the 2nd task then.
comparing to Shrinivas suggestion below, this approach might have advantage (depends on your requirements) that if membership of the Group changes, you assign 2nd task just to the approvers that were involved in first task and do not miss or add up ones
+8Hi Marian,
With the option you presented I believe why would you want to still send approval emails to people who have been removed from the Approvers group? It would be like if the Approvers were a bunch of directors and if one of them is taken off the group surely you wouldn't want to send the approval task to him?
Shrini
Shrinivas Naik, I'm sorry, I'm not sure I can follow your questions.
just to be sure, you are replying to my 2nd post (getting approvers from task list), right?
I just wanted to say that if between the timepoint task1 is being assigned and the timepoint task2 is being assigned list of group members change (some users might be added some removed), it's questionable whom should the task2 be assigned to.
I can see business cases when one or the other approach might be better (or even union of all such users). but that has to decide Gianluca for this case.
if I missed your point, please clarify in more details what exactly you see as a problem.
+1Excellent ideas Marian Hatala and Shrinivas Naik but unfortunately they don’t work in my scenario as I have to work with AD Groups inside of my SP Groups. This is an IT policy that I cannot change.
Let’s say I have a SP Group “HR-Approvers” and as a member the AD Group “HR-Management”.
If I follow Shrinivas’ Web Service idea, I get (of course) the AD Group as a result and not
a list of individual users.
Similar problem if I follow Marian’s idea: The workflow creates a task for the AD roup, and not for individual users, even if I tell flexi task to create ndividual tasks. Obvious…
So these deas would resolve part of the problem. The remaining problem is the extraction of users from (possibly nested) AD Groups.
+8Hi Gianluca,
You could use the same steps as I described above but instead of the step 2 where it loops assuming its a sharepoint group you could use "Query LDAP control" and query the AD group membership?. or may be a mix of both as you might have your SharePoint group contain and AD group as well as users.
Regards,
Shrini
I afraid then, you will not be able to achieve what you want - sharepoint is not able to enumerate AD group members, it just takes AF group as a final security object.
I have found a comparison here SharePoint Permissions Active Directory vs SharePoint Groups | IT Unity, that lists that as a disadvantage for theese kind of scenarios as well.
from my experience, using AD groups within SP group works quite well for security model (managing access rights) but is totally inappropriate for managing (logical) application/workflow roles.
+8Hi Marian,
Apologies was confirming the correct approach, you are right it could be the combination of any .. depending on what the business need is.
Cheers,
Shrini
+1Marian Hatala from a technical point of view you are absolutely right. It is more a resource problem. We don't have enough manpower to manage all groups in all our applications. So we try to use AD Groups as much as possible.
I can't confirm, but I think Shrinivas Naik is correct in that you could use Query LDAP to find members of an AD group.
If you have those members in a collection you can then save your approver of task 1 into a variable and then loop through the collection till you find a match, then clear the match out of the collection and work with the remaining members.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.