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 :-)
-- Jeremy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
