incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jastrac...@mac.com
Subject Re: [Agila] assigning tasks to groups of users
Date Mon, 08 Nov 2004 16:22:29 GMT

On 8 Nov 2004, at 15:58, Jeremy Boynes wrote:
> jastrachan@mac.com 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.


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


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


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

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.


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

James
-------
http://radio.weblogs.com/0112098/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message