Roles in workflows. When to use?

  • 31 May 2016
  • 1 reply
  • 2 views

Badge +7

Roles allow for finer tuning of grouping.  

 

Outside of that is it best advice not to use roles but AD groups when possible for workflows?


1 reply

Userlevel 1
Badge +8

There is a bigger philosphical question here is where is it gong to be best to manage group memberships. In K2, you have many options for managing these things such as K2 Roles, AD Groups, SharePoint Groups and lists of users from a data sources via Smart Object.

 

You want to pick a place that is going to be maintainable by the appropriate responsible parties so that the K2 development team doesn't get too weighted down by being apart of this task. 

 

For the most part, roles are purely just another way to group users that is managed by K2 wholely in K2. However, there are a few key distinctions.

  1. Roles can contain other groups for SmartObject lists.
  2. Roles can refresh their membership at runtime.

Number 2 is typically the most compelling feature. A role has the capacity (if enabled) to refresh itself on an interval. What this means for a workflow is say you have a role with 3 users. All 3 users receive a task. For some reason either one of the users leaves the company or a new user is assigned to that role. If the membership changes, the roles refresh functionality will automatically expire or assign workflow tasks to reflect the membership changes.

 

This can be a neat feature, but I don't see it used frequently because it fails a basic litmus test. I always ask my clients does the rate at which the user membership will change exceed the life expectancy of the task? The reason I ask this question is you have a weigh the benefits of the role to the management overhead you as a K2 Developer would be accepting for maintaining the role. If the task is short lived and membership changes infrequently there isn't any net gain or benefit as the membership doesn't change enough or the task doesn't stay alive long enough to warrant accepting the management responsibility.

 

What happens in most cases is the K2 Development team either handles task reassignment questions as they happen rather than adding additional overhead. Or, in the case of a recent post on this board, you can create some functionality to put the power of reassignment into different hands and completely remove the K2 dev team from the runtime conversation.

 

Finally, there is also the bigger institutional question of identity management. If you assigned a user to a role in K2 you will need to figure out a way to ensure that users are removed or added as people transition in and out of the company. AD Groups are generally part of a company's identity management strategy and therefore not something K2 developers have to worry about.

 

Good question, lots to consider on this topic.

 

S.

Reply