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