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.
10.4.1 Explicit and Implicit Condition Routing 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 conditional routing is that we mail a form to the client, which the client must fill in and return. If the user doesn't respond within a certain time-limit, we'll do something different from when the user does respond. But the decision needs to be made as late as possible, so we don't decide what way to go until we receive the form or our patience runs out.
Following is the complete list of permissions that I can think would be necessary and reasonable.
|
We need to be able to keep multiple versions of a process around. One of these will be the active version, which means that it's the one that'll be used for new cases.
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.
70.1 There should be a date, such that, if the user has stared, but not committed or rolled back the task before that timeout date, the task is automatically rolled back and the task is created again. There should be a callback to calculate that date.
Tasks can be assigned to specific parties.
80.1
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.
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.
There should be a repository of callback routines which can be used through the advanced process builder. They should include documentation.
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.
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. We'll need more information from marketing to determine this.
Start a new instance of the workflow around an object, e.g. when a new applicant signs up.
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.
There must be a way to query workflow attributes, so conditions, side-effects and other call-backs can use those in their code.
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? |
|---|---|---|---|
| 0.1 | Creation | 8/10/2000 | Lars Pind |
| Reviewed | 8/11/2000 | John Prevost, Mark Thomas, and Pete Su | |
| 0.2 | Revised and updated | 8/12/2000 | Lars Pind |
| 0.3 | Reviewed, revised, and updated - conforms to requirements template. | 8/22/2000 | Bryan Quinn |
| 2.0 | Added information on permissions and versioning. | 11/8/2000 | Lars Pind |
| Last Modified: $Date: 2001/03/13 22:59:27 $ |