Skip to main content

Dynamic approvers using K2 workflow

  • 8 August 2016
  • 4 replies
  • 46 views

Hi,

 

Can someone please guide if the below requirement can be done using K2? If yes any pointers would be great.

 

1) The K2 workflow starts when user clicks a button. It should first go to his/her immediate supervisor. After they approves it needs to go the supervisor's superisor. It follows this process until it meets the department head. (Department head needs to be identified by a specific job title). When the department head approves it, workflow needs to terminate.

 

2) For each department the number of levels mentioned in Step 1 will be different. Department A may have 2 supervisors and 3rd level would be Department Head. Department B may have 3 supervsiors and 4th level would be Department Head. 

 

Can this even be done using K2? Ours is a K2 standalone environment. K2 Blackpearl 4.6.11. 

 

Any suggestions would be greatly helpful.

 

Thanks,

 

Hi Rohni,

I do not know if K2 Bklackpearl Workflow default activity can be dynamically created on the fly. The best you can do is define all the possible routing and create a role for each destination user and assign to the default activity. You can later on add/delete user for each role anytime. That gives you a kind of flexibility on user role management. Please take a look at the workflow that might works for you. User selection on the department dropdown control will define the outcome of the action to route to the next route. You can also define in the line rule too.

The last default activity will terminate the workflow or you can write a server side code to kill the process or do nothing.

 

I hope it works.

 

14660i47A33568B3BB426E.png


There are actually a few different methods you could use to tackle this requirement. The most dynamic method would be to calculate and store your approval matrix at the start of the process. While this could be done in process datafields, I highly recommend creating a list of approvers and storing it in a SmartObject. This externalizes the list of approvers so that you have visibility into what the approval list looks like along with the flexibility of making tweaks to the list as any time during process execution.

 

Once you have the approval list/matrix saved, you could use the smart object in the destination rule for the review task. You could technically, use a plan one at a time setting on your destination rule and take all the users all at once, but then your hands are tied if you need to take alternate action based on if a lower level approver rejected.

 

What I would do is have a way to order my list of users in my matrix by some sort of ID field that I populated while I was building the list. I would sort the list by the order I want to approvers tasked. I would have field on that list to mark the user as having reviewed. This is so later when I am asking for the next user in the list I have a value by which to filter completed users out.

 

After a user actions the task, I would mark them as complete in my list of approvers. The next step of the process I would check to see if there were any more approvers, if so I'd loop back to the review task and task the next user in my list. I would repeat this process till all users had reviewed or some other criteria had broke us out of the cycle.

 

I have attached a quick mock up of this worklfow to this post. The pros of this approach is that the list of users is always visible and maintainable for each process instance for administrative purposes. The workflow will never be constrained to any preconcieved idea of how many users could be in a reporting structure so you could have 1 to Many potential approvers.

 

16283i5B075EC39E6B76F8.png

 

The main con to this approach is that if you are using view flow, it won't be readable by the end user as all the approvals happen in a single activity. In this case, I would opt for better workflow design and offer the business user an alternative reporting method if that was a requirement.

 

The how you populate the approver list is the big unknown here as there are other questions that would need to be addressed to fill in the blank on what would be the best way to populate the approver list. Most of this could potentially handled via Smartbox based Smart Objects which would keep the DBAs out of the development loop, but if you have access to SQL then a stored procedure option might provide for some flexibility for building the list that you might not have other routes.

 

Lots of options, just need to pick the one that fits best.

 

Hope this helps.

 

S.

 


Thank you Scott for your valuable suggestion. Your approach is truely flexible and externalize the approval logic in the matrix. Could you please show how to build the matrix smartobject (using storedprocedure ??), this will be a really nice example to handle such scenario that fixed route.


Thanks IPO and Scott for your detailed explanation. I will get to implementing this sometiem next month and I am sure I will have more doubts then.

I am saving this thread will re-open it when I actually start working.

 

Really appreciate your help!


Reply