Our K2 process has become very unwieldy, almost unusable because we've had exponential growth in worklist items.
here's our system in a nutshell:
*Custom Website/Database that displays/holds data regarding workflow items (folios)
*3 different groups of users, one of which needs to see (via the custom UI) every folio -- call them admins; the other folks need to see only items assigned to them (once these folks are done, their worklist item goes away).
*We never really "close" a folio, it remains around (thus the long term problem of exponential worklist item growth).
My question is, is there a way to change our plan such that we can have the admins see everything in the custom UI w/o creating worklist items for them? They need to be able to update these items (e.g., assign them to others, update data, etc).
+13
Can't you define a custom worklist that only displays the ones that have status of active? Can't the custom UI use a filter based on workitem status?
Also your custom UI probably is not supporting paging so it loads everything all the time into the list?
Also your custom UI probably is not supporting paging so it loads everything all the time into the list?
+1
I'm not sure what you mean by creating a custom worklist. Basically, I have one Folio/ProcessInstance that gets assigned to n folks and K2 makes a WorklistItem for each assignee. The folios always have a status of Active.
The way the UI works, it takes the user's AD credentials and performs a worklist lookup against the k2 db (using K2ROM which eventually calls kUserWorklist sproc).
One thought I've had is to assign everything to a generic AD user and then using the K2MNG api get the worklist item and go from there. So far, I haven't quite got that going.
Any other thoughts?
The way the UI works, it takes the user's AD credentials and performs a worklist lookup against the k2 db (using K2ROM which eventually calls kUserWorklist sproc).
One thought I've had is to assign everything to a generic AD user and then using the K2MNG api get the worklist item and go from there. So far, I haven't quite got that going.
Any other thoughts?
+13
Are you concerned about the number of records in the database or number of items displayed on the UI?
Do you expect these data to still last past x number of years?
"(once these folks are done, their worklist item goes away)."
When the workitem goes "away", is the one assigned to admin still active? Basically you made it a parallel route? Otherwise doesn't folio automatically close when it reaches the end of process map?
Aren't there permission for a specific process that allows the user to see every workitem? Assign that to your process admins.
Do you expect these data to still last past x number of years?
"(once these folks are done, their worklist item goes away)."
When the workitem goes "away", is the one assigned to admin still active? Basically you made it a parallel route? Otherwise doesn't folio automatically close when it reaches the end of process map?
Aren't there permission for a specific process that allows the user to see every workitem? Assign that to your process admins.
+11
Which version of K2.net 2003 are you running on? I'm sure the destination queue enhancements added to K2.net 2003 SP3 would suit your situation perfectly. In this version, you can create a destination queue for each GROUP of users and add these dest. queues as the destination users (nothing new here). In SP3, instead of creating a worklist item for each user within these groups, only one worklist item per group can be created - although all users will be able to see and act on the item.
Hope this helps,
Ockert
Hope this helps,
Ockert
+13
"only one worklist item per group can be created - although all users will be able to see and act on the item."
The lock would still apply right? If one person in the group opens the workitem would the workitem disappear from the rest of the group member's worklist? (Or does it display it as read only)
The lock would still apply right? If one person in the group opens the workitem would the workitem disappear from the rest of the group member's worklist? (Or does it display it as read only)
+11
If I understand you correctly, yes, the lock would still apply. Any user who is part of the group will be able to open the item and once opened, it will dissapear from the other user's worklist - after a refresh of course. That depends of course on the Filters applied on the worklist - let me rather say that once an item is opened by one user, the other user's item status will change to allocated - similar to normal worklist behaviour.
Regards,
Ockert
Regards,
Ockert
+1
The SP3 upgrade solved a lot! And yes, if somebody in the queue opens the workitem, it disappears from the queue.
Ideally, all of my queue users should be able to see any workitem regardless of who has opened it.
I tried to (behind the scenes) assign the worklist item to both the person who opened it and to the queue again, but I get this error:
System.Exception: The destination has a Queue assigned to it
at K2Util.ThrowK2(String s)
at SourceCode.KO.ActivityInstanceDestination.get_User()
at IndividualMailNotifier.get_ShouldSendMail()
at ClientEventHelper.SendNotificationMail(String relativeUrl, ClientEventContext K2)
at K2Code308.Main(ClientEventContext K2)
Anyhow, I think that I'm on the right track.... I'll report back when I figure something out.
Ideally, all of my queue users should be able to see any workitem regardless of who has opened it.
I tried to (behind the scenes) assign the worklist item to both the person who opened it and to the queue again, but I get this error:
System.Exception: The destination has a Queue assigned to it
at K2Util.ThrowK2(String s)
at SourceCode.KO.ActivityInstanceDestination.get_User()
at IndividualMailNotifier.get_ShouldSendMail()
at ClientEventHelper.SendNotificationMail(String relativeUrl, ClientEventContext K2)
at K2Code308.Main(ClientEventContext K2)
Anyhow, I think that I'm on the right track.... I'll report back when I figure something out.
+1
Quick Update:
--The error is mentioned in my last post is due to our custom code written in an event within k2 studio.
--Adding Queues and enabling create only one item is the way to go when you have a large volume of workitems that need to be seen by a lot of people. (see: http://kb.k2workflow.com/articles/kb000155.aspx)
--You HAVE TO close items or, "Keeping processes open indefinitely over time will doom your system's performance." (Thank you k2 support folks)
That last point seems like a duh thing -- worklfow implies an endpoint. We must be BRILLIANT at my company since we've redefined the term so that workflow is an ever swirling morass of workitems. I'll have to work on that one.
--The error is mentioned in my last post is due to our custom code written in an event within k2 studio.
--Adding Queues and enabling create only one item is the way to go when you have a large volume of workitems that need to be seen by a lot of people. (see: http://kb.k2workflow.com/articles/kb000155.aspx)
--You HAVE TO close items or, "Keeping processes open indefinitely over time will doom your system's performance." (Thank you k2 support folks)
That last point seems like a duh thing -- worklfow implies an endpoint. We must be BRILLIANT at my company since we've redefined the term so that workflow is an ever swirling morass of workitems. I'll have to work on that one.
Reply
View our Community Site Map
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.