> -----Original Message----- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: Monday, November 08, 2004 1:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [Agila] assigning tasks to groups of users > > [EMAIL PROTECTED] wrote: > > > > On 8 Nov 2004, at 15:58, Jeremy Boynes wrote: > > > >> [EMAIL PROTECTED] wrote: > >> > >>> Its very common with people workflow to assign a task to a group of > >>> users (or a role) rather than assigning it to a specific individual > >>> user. Then a user sees a list of all available tasks they could > >>> perform - they then grab one ('locking it') and then execute the task > >>> or releasing it back into the pool if they don't want to complete the > >>> task. > >>> Right now Agila uses a single UserID for assigning tasks. Unless I'm > >>> missing something, it looks like Agila needs some kind of 'role' or > >>> 'group' entity so that users can grab tasks rather than a workflow > >>> just assigning it directly to them. Or am I missing something subtle > >>> here? > >> > >> > >> I think there was a design trade off here around how that list of > >> users would be determined. > >> > >> One option is that when task is being generated, the actor resolution > >> process pre-calculates the list of users and assigns tasks to all of > >> them. When one of them completes their task, then all other > >> assignments are marked 'already-completed-by-another-user'. This means > >> the expansion process, which can be very expensive, is only done once. > >> It also means that there is a permanent audit trail of all tasks that > >> have been assigned to a user, whether they were the one who did them > >> or not. The downside, of course, is that a lot of assignments may be > >> generated and not used. > > > > > > Agreed. > > > > Its often better to just assign a task to a group and then let a user > > grab a task - again the same audit trail can be kept, but it can result > > in just 2 simple database operations rather than lots for large groups. > > > > In these situations the resulting number of users is often small making > for a very manageable set. The set is also defined by some correlation > id associated with the activity and so can be handled by two simple > database operations. > > > > >> The other option is to assign the task to a group deferring expansion > >> until a task list is displayed. The set of tasks returned is then > >> calculated based on the union of all groups to which the user belongs. > >> If there are more views of the list than there are assignments then > >> this may be a more expensive solution. > > > > > > Agreed - though its the more common approach on all the systems I've > > worked on in the past. e.g. folks often want to search the available > > tasks by role/group. > > > > Typically a users group membership is not that great (only a few groups) > > and the groups in which a user belongs does not change that often, so > > its common to be able to cache this around for a while, so the query of > > all tasks for 1..N groups is usually pretty cheap. > > > > Funny - I have seen systems collapse under such load even with caching > (the cost of a cache miss was too high when dealing with hundreds of > thousands of users). > > > > >> The audit trail is also more expensive as you have to record the list > >> of tasks that was calculated from the group membership expansion. > > > > > > I don't quite follow. So long as you've an audit trail of tasks to > > groups and users to groups, you're OK right? > > > > You have to generate audit events for the tasks that were displayed as a > result of the expansion. In the pre-calculated one you have specific > unique task-ids that can be logged. In the dynamic one you have to be > able to reconstruct the user/group hierarchy as it was at the time of > display. This involves an effective dating mechanism for users/groups > (which you would probably have anyway) plus way of making that data > available to the auditor. > > > > >> In certain business scenarios (especially HR, Finance or Health) the > >> group membership rules can be quite complex. For example, something > >> simple sounding like "get approval for my expense report" could > >> involve calculations to determine which managers have approval > >> authority based on the employee, the value of the report, the date of > >> the report, who "default" approvers (such as HR) are, and so forth. > > > > > > That sounds more like an approval workflow rather than just a group of > > users. i.e. if it requires complex logic to figure out what a group is, > > then its more about a step in the workflow chooses which users should > > get what tasks. > > > > It depends on how you view actor resolution. Yes, the rules for it can > be scripted by an analyst in the workflow itself (or in a reusable > sub-flow). Alternatively they can be managed by more specialized systems > such as a rules engine. Yes, you can have an activity encapsulate such > an agent, but I was trying to avoid having to write low-level iteration > code (e.g. to loop over a number of assignees) in the workflow model > itself - it just doesn't fir with what I see an analyst doing. > > > The group feature I'm more keen on is where you have groups of people > > doing similar roles who compete for tasks, taking tasks and completing > > them while avoiding dual work. > > > > This is certainly one model. Another is what I was describing as the > call-center model where work is more directed - it is the software that > determines what task to perform next and people often have little choice. > > > > >> In situations like this I believe pre-calculating the list of users is > >> more effective. > > > > > > Sure. I've just never had that requirement yet :) > > > >> > > > >> On the other hand, in applications like a call-center the expansion > >> rules tend to be determined less by business rules and more by the > >> dynamic nature of the pool; basically the task is assigned to the > >> worked pool and some queuing algorithm will assign it to a user based > >> on their availability. > > > > > > Or the user gets to choose what to work on. > > > > e.g. they have a task list of all pending tasks and they just pick one > > through the UI. > > > > > >> In that case, I believe the dynamic nature of the pool is outside the > >> scope of the business process. In other words, actor resolution in the > >> process would result in an assignment to the pool and not to > >> individual users. > > > > > > Agreed - that's what I want. > > > > > >> The call-center software would manage the mapping between the > >> assignment and which specific user was going to perform the task. This > >> could be done with a call-center-specific implementation of the > >> TaskService. > >> > >> Having said all that, it sounds like having the TaskService deal with > >> UserId (being a single person) is too limiting. > > > > > > Agreed. Especially because there could be a trivial 1-1 mapping between > > a group of users and an individual - so its really just an indirection > > to allow more flexibility > > > > > >> Given it needs to represent concepts such as a pool of workers in a > >> call-center, then some form of collective concept is needed. If this > >> is done then I think it is important to keep the notion of two phases > >> of expansion: > >> > >> 1) when converting from an actor to an assignee where the business > rules > >> may need access to information in the process instance (e.g. the > >> value of the expense report) > >> > >> 2) when determining the tasks that have been assigned to a user (i.e. > >> where they are or are a member of the assignee) which should not > >> need information from the instance > > > > > > Agreed. > > > > So how about we have some kind of Group entity and we provide access to > > assign a task to a Group and then let a user belong to 0..N groups and > > allow tasks to be queried by group? We can always keep the Task -> User > > mapping for those who want to follow the model of allocating tasks to > > all available users and then completing all of them when one person > > completes their task. > > > > I think we may be in violent agreement here :-) > > I think we should add some type of collective entity, I just hesitate to > call it a Group as that tends to be associated with a specific model ( a > relatively static set of users and other groups). Call it Assignee or > something and allow for more dynamic models :-)
Why not do something akin to JACC? Regards, Alan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
