Understanding PeopleSoft Workflow

This chapter discusses:

Click to jump to parent topicUnderstanding PeopleSoft Workflow

Many of the tasks that you perform throughout the day are part of larger tasks that involve several steps and several people working together. For example, when you enter an invoice, you are initiating an approval and payment process: someone else reviews and approves it, and a third person submits payment to the vendor. The term workflow refers to this larger process.

To a certain extent, all of the business processes that you define using PeopleSoft Application Designer involve workflow. However, we usually reserve the term to refer to processes that involve multiple users and the routing of data between the users.

Click to jump to parent topicUnderstanding Workflow Tools

This section discusses:

Click to jump to top of pageClick to jump to parent topicWorkflow Tools

You create and use workflow applications using several tools:


Click to jump to top of pageClick to jump to parent topicWork Items

At the center of a workflow definition is a set of business events and the routings that are associated with those events. A business event is a condition that tells the system that an activity is complete. For example, a new record has been created, a record field has a particular value, or a due date has passed. A routing is an instruction that tells the system to forward information to the next step in the business process. It specifies what information to forward and where to forward it.

When a user saves a page, the system determines whether an event has occurred and triggers the associated routings. For example, suppose an employee enters a change of address from an online page. An agent determines that the database has been correctly updated and may then add an item to the benefits administrator’s worklist to notify the insurance provider of the correct address.

In addition to adding work items to worklists, routings can send email messages.

Click to jump to top of pageClick to jump to parent topicWorkflow Triggers

Workflow routings are initiated by Workflow PeopleCode. The PeopleCode is assigned to pages, and when you save a page, it triggers a business event and its related routings.

Any process that can trigger PeopleCode can trigger a workflow event, including:

Click to jump to parent topicUnderstanding Workflow Application Development

This section discusses:

Click to jump to top of pageClick to jump to parent topicRules

Rules determine which activities are required to process your business data. For example, you might implement a rule that says department managers must approve all requests for external classes.

You implement rules through workflow events, such as PeopleCode that evaluates a condition and triggers a notification (a routing) when appropriate.

Click to jump to top of pageClick to jump to parent topicRoles

Roles describe how people fit into the workflow. A role is a class of users who perform the same type of work, such as clerks or managers. Your business rules typically specify which roles do which activities. For example, a rule can say that department managers (a role) must approve external course requests.

Roles direct the work to types of people rather than to individuals. Identifying roles instead of individual users makes a workflow more flexible and easier to maintain. Associating roles with users makes it easy to ensure workflow users the security access that they need to access the pages where they complete their work.

Roles remain stable, even as people change jobs. For example, if an employee in the Research and Development (R&D) department requests an external class, the system forwards the request to R&D Manager, not to Vic Rumpel, who is the current R&D manager. PeopleSoft application data serves as the basis for defining roles throughout your organization.

Click to jump to top of pageClick to jump to parent topicRoutings

Routings specify where the information goes and what form it takes: email message or worklist entry. Routings make it possible to deploy applications throughout the enterprise. They work through the levels and departments of an enterprise to bring together all of the roles that are necessary to complete complex tasks.

Click to jump to top of pageClick to jump to parent topicSteps for Developing Workflow Applications

Workflow development progresses through eight steps:

  1. Design the workflow application.

    Before you start developing workflow applications, analyze the business processes that you want to automate. Identify the goal of each business process, what its component tasks are, and how the tasks should be divided into smaller activities and steps. Articulate the conditions that trigger a workflow event and what happens when those conditions occur. Understand who your workflow users are and how you’ll determine who receives a work item.

    As you design the workflow application, identify the workflow rules and how they relate to the data objects and transactions in the PeopleSoft system.

  2. Build the underlying application.

  3. Create workflow maps.

    Use PeopleSoft Application Designer to create graphical maps that represent your business process. At this stage, you create maps only for the processes that are involved in the underlying application; you add PeopleSoft Workflow-specific elements to the maps when you define events and routings.

  4. Define roles and users.

    Define users’ roles when you give them their user IDs. Roles are important in PeopleSoft Workflow. To ensure that work flows to the correct person, you must determine who that person is. You can find the right person using either query roles or user list roles.

  5. Create a worklist record.

    The worklist record determines which fields of information the system stores for each work item, including the data needed to access the target page (the search keys for the page) and any additional information that you want to display in the worklist itself. Because different worklist entries can have different target pages and display data, you need separate worklist records for the different types of entries that will appear in the worklist.

  6. Define workflow objects.

    Events and routings are both objects on the workflow maps. To define these workflow objects, add the icons to the map, linked to the step representing the page where the triggering event occurs.

  7. Define event triggers.

    After you create workflow processes, link them into the PeopleSoft applications by adding PeopleCode programs to the pages. The PeopleCode detects when a business rule has been triggered and determines the appropriate action.

  8. Test.

    No development is complete until everything is thoroughly tested. Be sure to test under a variety of conditions, both usual and unusual.

Click to jump to parent topicUnderstanding Extended Workflow Capabilities

In addition to basic workflow events and routings, PeopleSoft provides extended capabilities that add to the power of workflow applications.

This section discusses:

Click to jump to top of pageClick to jump to parent topicRoute Controls

Route controls identify the aspects of a situation on which you want to base routing decisions, and they enable you to associate values with role users. For example, suppose you want to route purchase requisitions to different buyers, depending on which vendor supplies the ordered items, which business unit is requesting the items, which department needs the items, or some combination of these factors.

Route controls simplify the creation of role queries by enabling you to associate application data with the role user definition. Instead of joining together a group of records, you can look at the role user table. Another advantage of route controls is that the factors controlling routing are stored in a database table instead of in query definitions or PeopleCode. To change the routing rules, you change users’ route control profiles. You don’t have to modify the business process, role queries, or PeopleCode.

Click to jump to top of pageClick to jump to parent topicWorkflow Triggers from External Applications

A component interface enables third-party applications to enter data into PeopleSoft applications. It accepts data from a variety of sources, such as electronic forms software, interactive voice response (IVR) systems, or web applications, and from PeopleCode and Application Engine programs.

When a component interface sends data into the PeopleSoft system, PeopleSoft performs the same edits and security checks as it always does, including running any PeopleCode that is associated with the page. So if the page has associated workflow PeopleCode, a component interface can trigger a business event.

Click to jump to top of pageClick to jump to parent topicEIPs

PeopleSoft delivers a number of preconfigured EIPs to meet some of the more common integration needs. There are three PeopleSoft Workflow-related EIPs that you might use:

Click to jump to top of pageClick to jump to parent topicBatch Workflow Processing

Sometimes, the event that triggers a workflow routing is actually a nonevent. That is, a situation exists, but not because someone has entered data into the system. The most common examples of this type of event are aging processes. For example, an invoice becomes overdue, an employee reaches his five-year anniversary, or a worklist entry remains unworked for over a week.

PeopleSoft Application Engine enables you to monitor your database for this type of event. You can create an Application Engine program that runs a SQL query against the PeopleSoft database and passes the results to a component interface.

Using Application Engine programs in conjunction with PeopleSoft Process Scheduler, you can monitor the database tables for conditions that should trigger workflow events.

Click to jump to top of pageClick to jump to parent topicApproval Processes

Approval processes are a very common form of business process, and you can define approval rules on an Approval Rule Set map. The approval steps that you place on this map represent the approval levels required for the activity in question.

Two tools can read and implement the approval rules from the map:

Click to jump to top of pageClick to jump to parent topicActivity Guides

Activity guides support a specific type of workflow: a single user’s work across several pages. Because activity guides are intended for a single user, they do not involve routings like those found in a regular workflow application. Rather, the activity guide leads a user through a multistep task.

An activity guide appears as a navigation bar across the top of a page. Within the bar, you can see each of the steps involved in the activity. Clicking a step takes you to the page where you can complete the step; the navigation bar remains visible as you move from page to page.

Activity guides take a single map and integrate it into the pages that are used for the specific transaction. Although activity guides can benefit all users, they are particularly appropriate for guiding untrained users through self-service transactions.

Of the two kinds of workflow maps (business processes and activities), only activities are used for activity guides. The activity guide maps are built with the same tools as all other maps.

Click to jump to top of pageClick to jump to parent topicNotification Features

Within an activity definition, an event can trigger a notification routing in email or a worklist. These features facilitate sending notifications in workflow: