Interstage BPM Task Assignment Modes

• Posted by Keith Swenson August 8, 2012 - Filed in Technology - #Interstage  #Interstage BPM  #BPM  #Tasks  #Assignments  - 70,126 views

  1   Summary of Assignment Modes

  1.1  Static Assignment - Individuals

  The most basic way to assign to an activity is to put the name of a global group in the assignment field of the activity.  For example, in a bank loan process, you may have a fixed group of people, or maybe a single person, who is always needed to approve loans over a specific amount.  You would create a group named “Loan Approvers” which contains the people with this permission.

  The Individuals assignment means that at the time that the activity is activated, the members of the group are read, and individually assigned to the activity.  While the activity is active, that set of individuals will remain the same.  If the group is changed in the mean time, the currently running activity will not change.  This allows you to start and complete an activity with a consistent group of people.

  If another activity in the process is assigned to that group, it will re-read the members of the group, and the new activity will go to the current group members.

  1.2           Static Assignment – Pull To Me

  Whenever an activity is assigned to more than one person, it does not always mean that they are all supposed to complete the assignment, but instead that one of that group should pick up the task.  Interstage BPM has a built in mechanism for a single individual to “Accept” the task, and in effect pull it away from all the others.  Once accepted, the activity remains assigned exclusively to that one person until it is completed.  This allows you to make a process which does not attempt to guess which of the group is most appropriate, and allows the group members themselves to pull appropriate tasks to themselves.

  1.3           Static Assignment – Group

  When assigning to a group, there is an option flag that prevents the activity from reading the group members at the time it is started.  Instead, the activity is assigned to the entire group as an entity.  This means that the group membership is used at the time that user read the task, in order to control whether that user is able to access the task or not.

  This is useful in cases where the activity will remain active for longer periods of time, and the group membership is changing relatively faster.  With this approach, when you add a person to a group, they immediately gain access to all of the currently running activities assigned to that group.  Also, when you remove a person from that group, they immediately lose access to all those activities assigned to a group. 

  1.4           Static Assignment – Group – Pull to Me

  Assign a global group to the activity.  Access is limited to the group members at the time they try to access the activity.  Then, one member of the group can “Accept” the activity, which will convert the task to an individual assignement.  That individual will remain exclusively assigned to that task until it is completed (or until it is placed back).

  1.5           Static Assignment – Application Groups

  When we talk about groups, we normally mean groups specified in the LDAP directory server.  By simply using the name fo a group, Interstage BPM will go to the directory server and read the names of the member of the group.

  Starting with version 11, we have what are called “Application Groups”.  They are named collections of people, but that group does not have to exist in a directory server, instead it appears as a group at the level of the Application.  This means that when an application is installed on a BPM server, the application owner can then modify those group members for that instance of the application.  Typically an application will have 3 to 5 such groups which are needed by the particular needs of the application. The effect of this is that the application owner can control who is in the group, without needing to have administrative access to the corporate directory server.

  The application group is used transparently with LDAP groups.  The BPM system will look first for an application group with a particular name.  If not found, it will then look for a global LDAP group with that name and use that.

  1.6           Active Assignment – Script

  When the activity is initiated, there is a special phase called “role resolution” which will run Java Actions and/or Java Scripts in order to determine who should be assigned to this particular activity.  If there is a particular formula which can determine who is responsible at this point, it can be easily run.  An example of this would be having three groups each responsible for a given product.  Based on the value of the product UDA, the script returns the right group.  Once that is set, you have all the options normally available to groups:  accept will pull a task to an individual, and group-level assignment causes the group to be evaluated at the time that someone attempts to access the activity.  Script can be expressed either as JavaScript or as Java method.

  1.7           Active Assignment – Constrained

  In constrained mode, the process definition specifies a global group which represents the limit of the pool of people who can be chosen for the activity.  The dynamic assignment picks from that.  Actually, the activity is assigned to the union of the two sets.  This is used for some powerful situations.  For example, a large company may have a global group of “Compliance Controller” which is all the properly skilled people from all divisions.  The dynamic script would then specify the corporate division.  The activity will actually be assigned only to the Compliance Controllers from that particular division.

  1.8           Active Assignment – Decision Tables

  Sometimes there are a number of different UDA values which are relevant to specifying who is needed to do a particular activity.  In this case it is nice to lay the rules out in a big table, with columns for the UDA variables being tested, and then output columns to specify who is to be assigned.  In this case the appropriate people could be found depending upon the client location, product required, and estimated deal size.  The decision table makes it easier to manage complex associations.

  1.9           Active Assignment – Database

  In some cases you have another application which is maintaining the set of people with a particular skill, capability, or permission.   A DB Java Action can be used to access a DB table, and return the result of a query which specifies the people to perform the activity.  Like the decision table, UDA values can be used to form the query on the table, and this can be as complex as necessary.

  1.10      Active Assignment – Web Service

  If the database or application is remote to the BPM server, it may not be possible to access to access the DB directly.  There is an option to use a web service to retrieve the list of members to assign the activity to.

  1.11      Active Assignment – Application Variables

  Applications have global variables which can be set by application owners at the time that the application is installed.  These variables can contain any kind of values, and these values can be read by the scripts that run in the activities during role resolution.  An application variable might contain the specific name of a global group to use for this application instance.  This allows an application owner to change one variable, and all process definitions that reference that variable get the benefit of the change simultaneously.

  1.12      Dynamic Reassignment - Individual

  By reassignment, we mean that the assignment of an activity can be changed after it is started.  This is a specific feature of Interstage BPM.  In the Console, if a user ever finds that an activity is assigned to them which should really be assigned to someone else, there is a form to allow the activity to be immediately reassigned to one or more other people. It is possible to do this multiple times, so people can forward an activity until it gets to the right person.  The comment/discussion thread feature allows people to explain why they think someone else is appropriate, and ultimately to help lead to the resolution of the right person.

  1.13      Dynamic Reassignment – Manager

  A manager of a team has the ability to review the tasks assigned to team members.  If they see that a particular team member is overloaded, or underloaded, the activities can be reassigned dynamically from person to person in order to balance out the load. 

  1.14      Dynamic Reassignment – Automated

  Interstage BPM offers an API which allows the dynamic reassignment of tasks from person to person.  One can write a program to monitor the workloads of people, and to automatically reassign activities as necessary.  This requires programming.

  1.15      Role Based

  A role based approach is used when you have two or more activities that should be done by the same people, but the people are not globally fixed.  For example, when writing a magazine article, anyone might be picked up front to be the author, but there are often multiple different things that the author must do.  To support role-based assignment, we use a UDA variable.  Once the UDA variable (named ‘Authors’) contains the name(s) of the author(s), all the activities that the authors need to perform are set to be assigned to the people specified in the UDA variable.

  The UDA variable can be initialized through a number of different means.  It can be statically initialized; at process start-up time it might be read from an LDAP group; in many case there is a step int eh process itself to determine who is going to play the role in that process instance.  For example, the process to write a Magazine Article, there might be a field on the form to specify the author, or the reviewers, in one o the early steps of the process.  A form naturally stores information in UDA variables and the activity can then read this out of the UDA variable.

  If the role variable contains multiple people, all the same options exist about allowing a person to pull the activity to themselves by accepting the activity.  If the role holds the name of a group, then it is possible to use group-level-assignment such that members of the group at the time of access will control access.

  1.16      Role Based - Active

  The members specified by a role variable might be used directly and completely, but also can be manipulated by a script before assigning the activity.  One common use of this is to exclude one person from the list of assignees, known as the four-eye principle: a process instance must be approved by two people, and not the same person twice.  When completing the first approval, the person completing that activity is placed into a UDA variable.  Then, when assigning the second activity, the person who completed the first activity is excluded from the list of assignees.

  1.17      Role Based – Follow On

  One of the simplest role based examples is the case where you simply want to make sure that a follow on activity is done by the same person who did an earlier activity.  This is arranged simply by recording in a UDA variable the person who completes one activity, and then later using that UDA variable as a role to assign the later activity.

  1.18      Combinations

  Since roles are simply UDA variables, there are many ways that these can be combined to meet sophisticated needs.  For example, a decision table can be used to test a set of UDA variables (which might include role variables), and to update other variables, including role variables.  Web services and DB actions can be used to update role variables, which are subsequently used to assign activities.

  Custom Java Actions can be created by developers for business analysts to use in process definitions.  If a particular organization has a particular pattern that is used regularly, a custom Java Action can present a convenient user interface for that non-programmer to use.  For example, if a specialized web service provides dynamic group definitions to all the organization IT applications, a specialized Java Action might allow the user to browse those groups directly, without having to know anything about web services.

  1.19      Default – Error Conditions

  If any of the above mechanisms fails to identify a particular person, then the activity is assigned to the process  owner.  This is an important safety feature necessary in real world applications. If an expression is faulty, and returns an empty set of people;  or if a global LDAP group is removed from the directory; or if a decision table is edited and changed to miss a particular set of conditions, then the activities is always assigned to someone.  The idea is that the application owner will set things up to get notified about these error situations, so that they can use the reassign feature to immediately solve that problem, and then follow up by addressing whatever caused that problem in the first place.

  Similarly, if code within the process throws an exception for any reason (i.e. the DB is off line, or the web service is not available) the process will go into a special mode called “error mode”.  Process owners are notified when process instances go into error mode, so they can go look at them.  If the problem was temporary, then the process might simply be restarted when the DB or web service is back on line. If the failure is a permanent problem requiring a change to the process, they can redesign the process, migrate the existing instances to the new process, and continue all the processes running where they left off. 

  The ability to protect the process from errors, and to be able to recover from errors, is the key ingredient to allowing such things to be changed at any time while the process is running without fear of failure.