Defining a Workflow Application

A workflow can be defined as a series of activities or steps required to perform a specific business goal. Using a workflow application, you can electronically route documents for action or approval. This type of application allows users to electronically monitor and track the movement of documents. Workflow applications are ideal for documents that require multiple approvals or actions.

Let's take, for example, a procurement application where employees place orders for office supplies or equipment. To initiate the process, an employee completes a "procurement order" form and lists all items to be requisitioned. When complete, the order is electronically routed to an authorized person for review.

At this point, the approver can "approve" or "decline" the order. Similarly, the employee can withdraw the request. With each action, one or more emails are triggered to let everyone know the status of the requests and/or what actions are needed.

Approved orders are subsequently sent to a person in the procurement department. To keep track of their status, the person processing the order changes the status to "in process" after the order is placed and "complete" after the items arrive.

From a software perspective, the workflow application includes a form and emails. There are at least three people who are required to perform an action for each document. As the document is electronically routed, the status of the document changes and unique emails are sent with specific instructions to follow.

Figure 11.1 depicts the various paths the procurement order form can follow. The text in quotes represents the status of the document, with the person responsible for the workflow step in parentheses.

Figure 11.1. Process workflow

The design of a workflow application can range from very simple to complex. However, in general, there are several elements that tend to be common across all workflow applications. These items should be considered when building any workflow application.

• Workflow Stages Understanding the stages, or steps, that a document can take is critical to the overall development of a workflow application. To define the workflow, it's important to have input and participation from each person (or group) that will own a particular workflow step. As illustrated in Figure 11.1, you need to be able to map where a document can be routed and who specifically owns that step. Although this requirements gathering process is often time consuming, it's well worth your time to complete this early in the design of the application.
• User Roles The second most important aspect deals with roles and responsibilities. To build the application, you have to know who the key people are and what actions they can take. This will be used to build the application security (who can edit the document and when) and display formulas for action buttons (what actions can be performed). In the procurement example, there are three primary rolesemployee, approver, and procurement people. However, many workflow applications also include a person, or role, that has overall authority for the application, such as a system administrator. The administrator is typically responsible for the application configuration and in many cases has "super user" authority to perform any action or modify the application at any time.
• Document Routing Virtually all workflow applications are dependent on email routing. An action button typically triggers emails. However, scheduled agents can also trigger them. For example, if a particular person has not responded to (e.g., approved or declined) a document within a specified time, the system can automatically send a reminder notice. Emails are usually tailored to a particular status and person. In the following project, the emails are configurable and do not require programming intervention to change. All emails include a document link that allows the user to jump back to the document in the database (as opposed to sending a copy of the actual document).

  A.11.1

• Security Application security determines who can edit or take action on a document at any given point in time. For example, after the procurement form is submitted, it is locked. This prevents an employee from modifying the procurement request downstream. Security also prevents the employee from approving his or her own procurement order. Security is typically implemented at both the application layer and document layer.
• Action Buttons In most cases, actions buttons are used to manage or control the document workflow. As a document is routed through the various workflow stages, the buttons that are available will depend on the user's role, security, and "Hide When" formulas.
• Application Views Workflow applications tend to have many views. This provides users multiple ways to locate and track a document. For example, you could have a view such as "orders pending approval" and "orders in process". These views would be considered "work queues" for the "Approver" and the "Procurement" people.

In this chapter you will build a procurement order workflow application.