Workflows are graphical tools that are designed to help you manage the online automation of many types of business process or activity. Like scenarios, workflows track the progress of a subject through a specific process. In the case of scenarios, the subject is a site visitor, and the process is a series of events that define some form of activity on or related to your Web site. Workflows use a similar concept, except the subject is an entity such as a customer support case or a sales inquiry, and the process is a series of events that define the lifecycle of that entity. For example, you could design a workflow in which the subject is an online expense report and the stages of its lifecycle (the elements in the workflow) are submission, approval, and reimbursement.
The following illustration shows a workflow for an expense report. (Note that the illustration is broken into two parts, but the workflow itself contains no break.)
This workflow contains two tasks: Submission and Approval. The Submission task is completed by an employee, and the Approval task is completed by a manager. If the manager approves the expense report, the Reimburse Employee custom action is triggered; this action reads relevant information, such as the employee’s identity and the amount to reimburse, from the expense report repository, and it initiates the payment. The report’s status property in the repository is then set to “Reimbursed.” If the manager rejects the expense report, the report’s status is set to “Rejected,” and the workflow reverts to the Submission task, allowing the employee to revise his or her expenses.
You design the workflow in the ATG Control Center, and a page developer sets up any relevant site pages; including any forms necessary for completion of the different stages of the workflow. In the example of the expense report, the page developer could create a site page accessible by employees that includes an online version of a report and also contains a Submit button; and a page accessible by managers that includes a list of pending expense reports as well as Approve and Reject buttons.
The key differences between workflows and scenarios can be summarized as follows:
The subjects that progress through scenarios are site visitors; the subjects that progress through workflows represent other entities such as documents. (The subjects of scenarios are user profiles, but the subjects of workflows can be any repository item.)
Scenarios are used to track and respond to Web site activities such as page visit or login events. Workflows are used to track business activities that are completed either fully or partially through a Web site.
Scenarios are frequently used on extranets and commercial Web sites; workflows are frequently used on intranets or other Web sites that support a community of users.
The subjects progressing through a scenario have no direct interaction with it (participation in a scenario is completely transparent to the site visitor). Site users can, however, interact directly with a workflow.
Scenarios and workflows are derived from the same base package of code (
atg.process), but they use different subclasses of this code, and the sets of elements available for building scenarios and workflows in the ATG Control Center are different.
Important: You can create workflows only if your application developers have created custom workflow elements for your organization. You cannot create a workflow from a default set of elements as you can for scenarios. For more information on this restriction, see Creating a Workflow.
This chapter includes information on the following topics:
