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 15:58:53 GMT 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.

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. The audit trail is also more expensive 
as you have to record the list of tasks that was calculated from the 
group membership expansion.

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.

In situations like this I believe pre-calculating the list of users is 
more effective.

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 

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. 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. 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


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

View raw message