ACS Documentation : Workflow : Workflow Requirements
In the ACS, we have several modules that define such processes, including:
In the current system, the rules for the state transitions are encoded in the logic of the pages that make up the module that defines both the object type and the process.
The motivation for the workflow module is to define a more abstract and reusable mechanism for describing these processes.
Annie Administrator uses the administrative user interface to formally define her workflow, and she defines that objects in the technical support knowledge library will be processed according to this workflow.
Tracy Techsupporter submits a new item to be included in the library. The workflow package (triggered by a hook in ACS Core) will start a new workflow case around the item. This in turn will trigger an email notification to Mike Moderator (and other moderators, if there is more than one person capable of performing the moderator task), informing him that he now has a new item on his work list. The email will contain the URLs for both his work list and the new item.
When Mike Moderator visits his work list, he'll see the list of tasks that he has reported to be currently working on, and a list of tasks he is capable of performing, ordered by priority. When he clicks on one of these tasks, he'll get to a page with information about the task to perform like this: Mike Moderator decides to work on this task and clicks the Start task button. The output pane now changes to look like this:
At the same time, the task dissappears from the other moderators' work lists. Mike Moderator does his work and picks two reviewers, then hits "Finish task". This pushes the case to the next step, which will add two tasks, one for each reviewer, to review the item.
Randy Reviewer and Rick Reviewer will do essentially the same thing as Mike Moderator: They'll receive an email that there's stuff for them to review, go to the task page info page to see what to do, and do their jobs. Their "action" pane will look like this: The reviewer chooses "Author must revise item", which causes a new task to be created for Tracy Techsupporter to revise her item. She does, and when she says she's finished, new tasks are created for the reviewers to re-review the item. This time, they're happy, and a task is created for Charlie Categorizer to categorize the item. He does, and the workflow ends with the item being included in the library.
The system must support the following forms of routing
Two tasks are to be performed one after the other. This is the most common routing construct in real-world workflows.
Two tasks are to be performed simultaneously or in no particular order. This is essential for improving the throughput of a workflow, since performing two tasks in parallel are likely to be faster than performing them sequentially.
A set of tasks can be performed one or more times. The ticket-tracker has an example of this routing, in that the ticket can go to "fixed, awaiting approval" and back to "open" as many times as is necessary to finally reolve and close the ticket.
One or another task is to be performed, depending on some condition. This is often used to implement iterative routing, in that the condition determines whether we should perform one more iteration or not. Also, take approval of expenses as an example. It would be common to make the approval process different, depending on the amount in question, e.g. if it's a small amount, the applicant's supervisor can approve the expense, or if it's a very large amount, both the CEO and the chairman must approve it.
The decision can be made either as we're finishing the prior task, or as we execute one of the two conditional tasks. The above example is one of explicit conditional routing. An example of Implicit conditioning, is a restaurant owner purchases perishable goods, such as meat and vegatables. The food items sit in a queue waiting to be processed into meals or wait for 15 days (meat and vegatables tastes change after 15 days). If the task "wait for 15 days" is completed, then the food item is thrown away. The routing is determined by the first task to execute.
The item that the workflow is about will always be part of the input, but there should be the option of presenting other information. Static text will do for now.
Each task will contain more detailed information on what is expected to be done and instructions to the person executing the task on how to go about executing it. Static text will do for now.
A task can have a number of values as output. Examples include "review_comments", "review_conclusions" as above. We should be able to use these values in conditions for conditional routing.
The execution of a task must be atomic to the system. Either the task completes or it doesn't do anything. But in the real world, a task takes time, so we must have a "start", "commit", "rollback" meachanism.
Tasks are not assigned directly to users, instead we associate roles with a task. A role is granted to a single or a group of users. Users belonging to that role have execute privileges on the task associated with role.
There should be some mechanism of prioritizing tasks in the work list. How to do this is yet undefined. A call-back seems desirable, but we need to determine when or how often the call-back should be executed (i.e. how often will we allow priorities to change).
90.1 Deadline
Each task can have a deadline, a date by which is must be performed. This is determined by a call-back as the task is created.
90.5 Completion time A task has an entry to estimate how long it will take for completion.
Note: Defintion of deadline is unclear: is it per case or per task? I.e., if a task is entered twice, will it have the same deadline both times, or will it have a new deadline the second time around? Or option of both?
The users should automatically be alerted when there's a new task for them to perform.
100.1 Not fully specified: It should also alert them when the deadline is nearing, when the priority changes, and possibly on other conditions.
There should be a callback mechanism allowing for side-effects at certain points in time.
A task can be "automatic" in the sense, that it is only there for the side-effects. It is automatically finished as soon as it is created.
120.1 Timed automatic tasks
Alternatively, we can specify a specific point in time, the automatic task should finish. This is useful for timeouts, e.g. when waiting for a client to return a form, we may cancel the case if we don't hear back within a month. The point in time is determined via a call-back.
120.5 Message tasks
A message from an external source can be passed to the task. The task is executed upon receiving the message and all the criteria placed on the message are satisfied.
The user can post a comment on a task at any time during the life-cycle of the case . The comments are shown to the users, so they can use them as a guidance in processing the case.
The same workflow definition may be applied in several different departments of the same company. In this case, the department will be the context of the workflow. In other situations, the same workflow definition may be applied within separate companies running on the same site. In this case, the company is the context.
The things that are dependent on the context are:
Note! It may or may not be the case that a context will always also be a subsite, in which case we don't need any additional concept to model this situation.
Start a new instance of the workflow around an object. Currently it is not possible to have a callback in the kernel upon new object creation. This requires programmically calling the method to start a new case.
Cancel/suspend/resume the overall workflow process, e.g. if an applicant backs out of the process, or the administrator decides the processing must wait a while before continuing.
The API must provide for starting/finishing/canceling tasks.
220.1 Finishing the task includes storing the output of the task in attributes attached to the workflow instance.
Attributes for a process to use for branching and keeping state
properties.
230.10 Add and Edit attributes attributes per case
230.20 Access to those attributes values in the callback
procedures
The user should have a work list page showing all the tasks he's supposed to perform. It should be ordered by priority/deadline.
See the user-scenario for a sample page.
A page where you can get an overview of how a particular workflow is going overall, i.e., how all the workflow instances are doing. It's tough to come up with a good visual design of this that will give the quick overview. Needs to be thought more about. Probably not a first version thing.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 2.3 | Minor edits | 04/13/2001 | Khy Huang | 2.0 | Added information on permissions and versioning. | 11/8/2000 | Lars Pind |
| 0.3 | Reviewed, revised, and updated - conforms to requirements template. | 8/22/2000 | Bryan Quinn |
| 0.2 | Revised and updated | 8/12/2000 | Lars Pind |
| Reviewed | 8/11/2000 | John Prevost, Mark Thomas, and Pete Su | |
| 0.1 | Creation | 8/10/2000 | Lars Pind |
| Last Modified: $Date: 2001/11/19 18:31:50 $ |