AD Groups as destinations

  • 3 August 2009
  • 2 replies
  • 1 view

Badge +1

The K2 workflows that I am using assign the workflow to an AD Group rather than a specific user.  These teams are allocated based upon a WCF service call within the workflow (we use WCF in preference to Smart Objects).

This means that we don't need to worry about delegation.

The only problem that we are having is when we want to add a user to an existing group.

It appears that K2 when processing an Action expands the members of the AD Group to create the destinations. This means that a user added to an AD Group after the action was established can't perform any actions on the worklist item (until it has been transitioned to a new state). More worringly the reverse is also true - remove a user from a group and they can still perform one action on each workflow before the new group structure is applied.  Does anyone have a solution to this problem?  I have looked at the paper on Roles and Advanced Destination Rules but it does not quite allow for what I want - 1 slot per activity actionable by any one member of an AD Group but does not expand (and cache) the AD Group into it's component members.

I know that the solution will involve a dynamic role - but I need to be able to assign the role in code (preferably without the use of a Smart Object). We are using a custom view to display the activities so I am not sure that the dynamic roles would be triggered - we make a lot of calls into OpenWorklistItem not OpenWorkList which the documentation claims will trigger a dynamic group update.


2 replies

Badge +5

Hi Chris


 Have you attempted to use the Dynamic Roles along with the Keep Roles in Sync option ? What this will do is that everytime a User logs in it will re-evaluate the Destination Rule and match it up with the logged in Users permissions . If the User is no longer part of the Role the WorkList item will be removed from his WorkList and vica versa if he has been added to the Role .


 Q

Badge +5
I second this approach.  This is precisely why dynamic K2 roles exist. 

Reply