You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by ja...@mac.com on 2004/11/08 16:08:35 UTC
[Agila] assigning tasks to groups of users
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?
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
Re: [Agila] assigning tasks to groups of users
Posted by "David H. DeWolf" <dd...@apache.org>.
What about ResponsibleParty?
David
Jeremy Boynes wrote:
> jastrachan@mac.com wrote:
>
>> On 8 Nov 2004, at 18:53, Jeremy Boynes wrote:
>>
>>> 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 :-)
>>
>>
>>
>> Cool; I'll submit a patch.
>>
>> Assignee sounds a bit vague; how about Workgroup, Role or Team?
>>
>
> That kind of leaves out the poor old individual user but I agree
> Assignee is a weak name - better than "ThingToAssignTheTaskTo" I guess
> although that could be refactored later :-)
>
> Given those, Role would be my choice although that tends to get
> overloaded as well. I have seen "Role" used by a few different business
> communities so it may fit their world view well.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Agila] assigning tasks to groups of users
Posted by ja...@mac.com.
On 9 Nov 2004, at 14:54, Jeremy Boynes wrote:
> jastrachan@mac.com wrote:
>> On 8 Nov 2004, at 18:53, Jeremy Boynes wrote:
>>> 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 :-)
>> Cool; I'll submit a patch.
>> Assignee sounds a bit vague; how about Workgroup, Role or Team?
>
> That kind of leaves out the poor old individual user but I agree
> Assignee is a weak name - better than "ThingToAssignTheTaskTo" I guess
> although that could be refactored later :-)
:)
> Given those, Role would be my choice although that tends to get
> overloaded as well. I have seen "Role" used by a few different
> business communities so it may fit their world view well.
Agreed.
How about adding another word to make it more specific - WorkflowRole,
WorkGroup or ActivityGroup or something?
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
Re: [Agila] assigning tasks to groups of users
Posted by Jeremy Boynes <jb...@apache.org>.
jastrachan@mac.com wrote:
> On 8 Nov 2004, at 18:53, Jeremy Boynes wrote:
>
>> 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 :-)
>
>
> Cool; I'll submit a patch.
>
> Assignee sounds a bit vague; how about Workgroup, Role or Team?
>
That kind of leaves out the poor old individual user but I agree
Assignee is a weak name - better than "ThingToAssignTheTaskTo" I guess
although that could be refactored later :-)
Given those, Role would be my choice although that tends to get
overloaded as well. I have seen "Role" used by a few different business
communities so it may fit their world view well.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Agila] assigning tasks to groups of users
Posted by ja...@mac.com.
On 8 Nov 2004, at 18:53, Jeremy Boynes wrote:
> 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 :-)
Cool; I'll submit a patch.
Assignee sounds a bit vague; how about Workgroup, Role or Team?
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
Re: [Agila] assigning tasks to groups of users
Posted by Jeremy Boynes <jb...@apache.org>.
jastrachan@mac.com wrote:
>
> 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.
>
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Agila] assigning tasks to groups of users
Posted by ja...@mac.com.
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
Re: [Agila] assigning tasks to groups of users
Posted by Jeremy Boynes <jb...@apache.org>.
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.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org