incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: [Agila] assigning tasks to groups of users
Date Mon, 08 Nov 2004 18:53:48 GMT wrote:
> On 8 Nov 2004, at 15:58, Jeremy Boynes wrote:
>> 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 :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message