Configuring Work Order Approval Workflow

This chapter provides an overview of the work order approval workflow architecture and discusses how:

Understand the work order approval workflow architecture.
Revise the delivered work order approval workflow.

Understanding the Work Order Approval Workflow Architecture

To ensure that all work orders have proper authorization, the system is able to dynamically route work orders to the appropriate people for approval using business rules that you establish for your organization, based on your particular business needs. This section discusses:

Terminology.
Architecture.
Work order approval workflow modifications.

Terminology

This table provides definitions for the work order workflow terminology that is used throughout this chapter:

Ad Hoc Approver/Reviewer	Technician or approver can add another user ad hoc to approve or review the current work order only. The process definition is not modified, so it does not affect other work order approval routings.
Approval Map	The graphic representation of an approval instance with stages, paths and steps.
Approval Path	A path is a group of sequential, related steps, such as approval steps based on a single department hierarchy (for example, manager, director, VP, and so on).
Approval Stage	A stage is a collection of paths. Stages come in a single sequence (stage 1, stage 2, …). A stage runs when it’s immediately preceding stage finishes. When a stage runs, all the paths within it run simultaneously. The stage is considered complete when all paths within it have finished.
Approval Step	The basic unit of approval. A step has one or more approvers, whose actions are tracked. A step can be configured to require a set number of approvers to act and has criteria that govern whether or not the step is to be active for the work order.
Approver	Manager or maintenance planner who is responsible for approving the work order.
Criteria	A criterion is an entity, which evaluates to true or false. Criteria are used to determine which steps and paths are to be considered active for a particular request undergoing approval processing. Criteria can be configured by the functional analyst or can be canned queries, SQL objects, app classes, and so on.
Reviewer	The application routes work orders to reviewers for informational purposes, but reviewers do not need to take any action for the approval process.
User List	Approvers, reviewers, and other actors are grouped by roles and other means. SCM Approval Framework provides an abstraction across such aggregates, called Userlists.
Work Order Approval Process Definition	A set of rules to govern how the works order approval process should flow for a business unit (setID-based sharing) based on the business requirements. Within the process definition, stages, paths, and steps can be defined with different criteria and approver designations.
Work Order Approval Process Instance	A running instance of the approval process for a particular work order with criteria evaluated and specific approvers known (routed or not routed).

Architecture

The work order approval workflow uses the workflow framework provided by PeopleSoft Enterprise Supply Chain Management, rather than the standard PeopleTools workflow, which requires advanced technical skills in PeopleTools. Consequently, the PeopleSoft Maintenance Management workflow is easy to create and maintain. All the steps in the work order approval workflow are defined using PeopleSoft pages and are designed so that functional users can easily set it up.

PeopleSoft Maintenance Management delivers the work order approval workflow engine preconfigured. We recommend using the delivered configuration as is, making minor modifications to suit your particular business practices. The work order approval is delivered as system data, using the WM_WORK_ORDER approval process ID. You can modify the definition to suit your implementation by defining your own phases, steps, and criteria. These definitions control who should approve the work order, the order in which they approve it, and the method by which the system routes it to approvers. The approval process is keyed by setID, and by using setID sharing, each business unit can either have its own independent work order approval process configuration or share the same approval process configuration with other business units. We recommend that you understand the workflow technology before making any changes.

See Using Workflow and Managing Approvals.

Work orders are routed to approvers so that they can act on the work orders to approve or deny them. If the approver approves a work order, then it is routed to the next approver, if any. A submitter or approver can add ad hoc approvers for the current work order as well. After the work order is fully approved (or no approval is required), it is available for a scheduler to schedule technicians to perform the work. If the approver denies a work order, than the approval process is terminated. The submitter is notified of the denial and can optionally revise the work order and resubmit it. The technician can choose to cancel a work order; and if an approval process is in progress, it will be terminated.

The following elements are used in the work order approval process definition and are among the items you would modify to suit your business requirements:

Stages.

A stage is one part of an approval process that can contain multiple parallel paths. The system executes stages in sequence where one must complete before the next one begins. A stage consists of one or more paths.
Paths.

A path contains a sequence of steps. Within a stage, paths execute in parallel. Path entry criteria determine whether a path executes for a given work order.
Steps.

A step represents one or more approvers or reviewers. Steps within a path execute in sequence. Separate criteria for each step determine whether or not that step executes. Each step can also have a set of reviewers, who are notified about transactions pending approval by email, if configured, and through the Worklist. But the workflow proceeds without waiting for reviewers to act.

Note. While the approval process configuration may require any number of approvers to approve a step before it advances, any single approver can deny a work order. After a work order is denied, the system stops routing the work order, the approval process terminates, and the entire work order is denied.

The system notifies approvers of a pending approval by using Worklist and email. You need to define the individuals or roles that comprise a user list, and the authorized approvers. You can specify approvers by roles, queries, fixed lists, or by using custom application classes. Once the required number of approvers have approved a step, the approval workflow advances past that step.

The following diagram illustrates the overall process flow for the work order approval workflow process:

Work order approval process flow

Work Order Approval Workflow Modifications

To make adjustments to the delivered work order approval workflow process, complete the following tasks, which are discussed in detail in the remainder of this chapter:

Update the work order approval process definition by using the Approval Process Definition component.

The approval process definition specifies the stages, paths, steps, and criteria for the workflow approval process.
(Optional) update the method of notification that is used for approvals by using the Approval Transaction Registry page.

The transaction definition contains the metadata which describes the transaction make up to the workflow approval engine. PeopleSoft delivers the transaction registry for work order approvals; you do not need to create it. As delivered, the system is configured to use emails and worklists.
Add or update user lists by using the User List Definition page.
Add or update work order approvers by using the Authorize Approvers page.

Revising the Delivered Work Order Approval Workflow

This section discusses how to:

Modify the approval process definition.
Define approval criteria.
Define approval paths.
Define approval steps.
Authorize approvers.
Modify approval notification options.
Define generic notification templates.
Maintain user list definitions.

Note. This documentation discusses only the fields that apply to PeopleSoft Maintenance Management. Information about the remaining fields are described in the PeopleSoft Enterprise Supply Chain Management 8.9 Common Information PeopleBook.

See Using Workflow and Managing Approvals.

Pages Used to Revise the Delivered Work Order Approval Workflow

Page Name	Object Name	Navigation	Usage
Approval Process Definition	SAC_AW_PRCS_MAIN	Set up Financials/Supply Chain, Common Definitions, Approvals, Approval Process	Establish work order approval process definitions.
Criteria Definition	SAC_CRITERIA	Click the Criteria link on pages within the Approval Process Definition component. Click the Self-Approval Criteria link on the Step page.	Define criteria for workflow approvals.
Path	SAC_AW_PATH_SEC	Click the Path Details link on the Approval Process Definition page.	Set up workflow approval paths.
Step	SAC_AW_STEP_SEC	Click the Step Details link on the Approval Process Definition page.	Define steps for workflow approvals.
Authorize Approvers	SAC_AW_AUTH	Set up Financials/Supply Chain, Common Definitions, Approvals, Approval Authorization	Define approvers for the work order approval workflow process.
Approval Transaction Registry	SAC_AW_TXN	Set up Financials/Supply Chain, Common Definitions, Approvals, Approval Transaction Registry	Specify the notification method to use for work order approvals. The transaction definition is the metadata that describes the transaction make up to the approval workflow engine. The remaining fields should not be modified.
Generic Template Definition	WL_TEMPLATE_GEN	Setup Financials/Supply Chain, Common Definitions, Approvals, Generic Templates	Enter template definitions for ad hoc approval notifications.
User List Definition	SAC_USER_LIST	Setup Financials/Supply Chain, Common Definitions, Approvals, User List	Define user list definitions.

Modifying the Approval Process Definition

Access the Approval Process Definition page using the WM_WORK_ORDER approval process.

Preview

Click to view how a workflow instance would function when it runs.

Approval Process Builder

Click to access a graphical tool that enables you to view each stage, path, and step of the approval process.

Note. When you are viewing the graphic tool in the Approval Process Building page, if you elect to make changes the system will return you to the standard Approval Process Definition page.

Set ID

Identify the set ID for the workflow approval process.

Effective Date

Specify the date on which this approval process is effective and ready for system use. This applies to approval processes for a particular approval process ID and setID and includes PeopleSoft functionality associated with effective-dated entities. For instance, if multiple approval processes are active with the approval process ID, setID and effective date specification, then the system uses the latest active effective-dated process.

Status

Select the current state of this approval process. The values are:

Active: Indicates the approval process is available for use.

Inactive: Indicates the approval process is not available for use.

Admin Role (administrative role name)

Select the user list role to route the transaction to if an error occurs during the work order approval process.

Note. The error conditions are no approvers or not enough approvers.

User Auto Approval

Select to enable the system to remember an approver’s action for this process. The next time this approval process is presented to the approver, the system automatically applies the approvers selections. The automatic application of steps in the process is left in place until you clear the User Auto Approval check box.

This applies to the specific work order the approver had previously approved in this process only.

Route to Requester

Route to Requestor works in conjunction with the Self Approval flag. If the approver failed to meet the self approval criteria, the approval could still be routed if this check box is enabled. If the check box is not enabled and the approver fails to meet the self approval criteria, then the system routes the approval to the administrator.

Alert Criteria

Click to access the Criteria Definition page where you can define user and field criteria along with monetary and application class criteria for this stage.

See Defining Approval Criteria.

Stage

Enter the sequence in which you want this stage of the approval acted upon. You can also enter a description for the stage in the Description field.

A stage is a logical grouping within a process, such as commodity or fiscal approval. You can define a single stage or use multiple stages, in which case the stages execute in strict sequence. Before the second stage starts, the first stage must end.

Each stage must be either at the header level or at the line level. This is the additional constraint on header- versus line-level approval configurations. A header-level stage acts on the single header. A line-level stage acts (simultaneously) on all the lines under the header.

Note. For PeopleSoft Maintenance Management work orders, approval is done at the header for the entire work order, not for individual work order tasks, and only the header level is supported.

Level

Select Header. At a header-level stage, the system enables the same request (header) to be routed to two or more parallel paths. Line level approvals are not supported for work orders.

Approval Path

Enter a value that identifies this path. A path is a sequence of steps.

Within a stage, paths execute in parallel with each path at the level from the stage to which it belongs. Path-entry criteria determine whether a path executes. If the system evaluates the criteria you enter for a path to be false then it bypasses that path.

When a stage becomes active (approvers in the stage get pending work), all its contained paths become active simultaneously. All the paths of a stage queue work to approvers in parallel. The stage is complete only when all paths in it complete.

Source

Select the method by which steps are instantiated during the approval process. Values are:

Static: Select this source to indicate that you want the system to use the individual user-defined steps when it processes an approval.

Dynamic: A dynamic path definition contains only one step. When begun, the single step definition could yield any number of instances in sequence.

When using the Dynamic source, the system uses the user list on the step definition to initialize the steps in the path. The single step definition is repeatedly run, until the step's user list returns no more approvers. All these instances are queued in sequence.

User lists are associated with queries and classes using the User List Definition page. To access the page, select Set Up Financials/Supply Chain, Common Definition, Approvals, User List.

Path Details

Click to access the Path page where you can define path criteria and escalation parameters, such as whether or not to notify the requester's supervisor.

Criteria

Click to access the Criteria Definition page where you can define field criteria along with monetary and application class criteria. You can define criteria for the approval process using most records and fields in the database. The system uses these criteria as entry criteria for both the path and step.

Step

The sequence in which you want this step performed during the approval process. Use the arrow icons to move a step up or down in the sequence of steps.

Approver User List

Select the type of approver you want to use for this step. A user list is an entity which groups users in the system. Roles, queries and application classes are examples of user lists. The system then uses the list and its users to run automated business processes. The list defines the user sources who can be used in approval steps.

When configuring approval workflows, business analysts use user lists to assign approval tasks to the approvers and reviewers who are to act on the request being considered for approval.

The approval engine has two types of contextual information available to the user list definition: the previous approvers in the path, and the transaction (header or line) keys. The previous approver of the first step of a path is always the requester, regardless of which stage the path belongs to. In the case of SQL queries, the context is provided by bind values. The bind values are the prior approver (one per call, in case there are multiple prior approvers) and the keys of the header record. The key values are provided in the order in which they are defined in the corresponding record object.

Step Details

Click to access the Step page where you can define approver requirements, self approval details, and reviewers.

Defining Approval Criteria

Access the Criteria Definition page for the WM_WORK_ORDER approval process.

Use this page to define the different types of criteria that you want to apply to a workflow approval process. You can create definitions consisting of a field with a logical operator and a value or definitions consisting of an application class that takes in transaction data to process the approval.

Criteria is an entity which evaluates to true or false. It programs the approval workflow engine, using transaction-specific information to change, for example, routing paths. In order to set the context for the criteria, the engine provides the transaction keys as bind values.

If you access this page using the Alert Criteria link, you can define criteria for the overall approval process definition. If you used the Criteria link to access the page, you can define criteria for steps or paths, depending on the section from which you access this page.

Criteria Type

There are three different types of criteria you can enter:

The system will only follow paths that evaluate as true. Always True informs the system to trigger this workflow approval process. No criteria is needed.
With the criteria typeApplication Class you define which specific application class the system uses to determine if the workflow approval task evaluates as true.

Note. Use the Application Class criteria type when the user entered criteria does not contain the necessary level of detail.
Use the criteria type of User Entered Criteria to enter all record and field combinations either value or monetary based, that will trigger the workflow to evaluate as true.

All Criteria Needed to Satisfy

Select this check box to require that all criteria defined on the Criteria Definition page must be met in order to trigger the workflow.

User Entered Criteria

Use this section to define additional criteria for the approval.

Description

Enter purpose of the alert.

Field Criteria

Use this section to select a record and field on which to control and filter ranges of data or types of data placed in the file that you want to use in the approval process.

Record	Select a record that you want to use in defining approval criteria. For example, if you were indicating a type of work order, you would identify WM_WO_HDR as the record.
Field Name	Select a field that you want to use to define approval criteria. The values you define in the remaining field criteria grid are those that are used in determining the approval criteria.
Criteria Operator	Determines the action the system applies to the criteria you enter in the Value fields. These operators are available: Between: Use only values between the two values you enter as criteria. Equals: Use only values equal to the entered criteria. Greater Than: Use values equal to or greater than the entered criteria. Is Blank: Evaluates to true when the specified field contains a null value. Is Not Blank: Evaluates to true when the specified field does not contain a null value. Less Than: Use any record value that is less than the value entered in the Operator Criteria field. Not Equal To: Use any record value that is greater than or less than the entered criteria. Not Equal To: Use any value that is not equal to the two values you enter as criteria.
Value	Use the two Value fields to define a range upon which you want to base the operator criteria.

Monetary Criteria

Use this section to establish approval criteria for work order amounts. The system uses the values you define to determine the routing for approving the work order. When the system evaluates the criteria for an approval process or a step or path within the process, it uses monetary values you define in this section.

The system uses values from fields in this section in conjunction with the Operator field to determine whether to run a step.

Amount Record	Select the record name to be used when comparing the work order to the minimum amount required to trigger the step.
Amount Field	Select the field within the amount record to be used when comparing the work order to the minimum amount required to trigger the step. The system uses the value that you select to evaluate the Amount field.
Currency Field	Select the currency field that corresponds to the currency code you select in the Currency Code field.
Operator	Select a value that determines how the system processes the values in the Amount fields. Values include Between, Greater Than, and Less Than.
Amount	Use the Amount fields to define an amount range for use with the Operator field. In the first field, enter the minimum amount required on the work order to trigger the step. The system identifies all lines in the work order that meet the criteria defined in the Amount Record and Approval Field fields. The amounts on these lines are totaled based on the amount record and amount field specified. If the work order total is higher than this minimum amount, the criteria is met. If no amount is specified, zero is considered the minimum.
Currency Code	Select the monetary unit that you want to use for the approval.
Rate Type	Select how the system arrives at the currency value, such as the current rate or a financial rate.

Application Class Criteria

These fields are not used for work order approval workflow and are unavailable for entry.

Defining Approval Paths

Access the Path page.

Use this page to set up additional parameters that determine how the system processes an approval path. Use the escalations feature to define time elements for when an approver takes too long to approve or deny a pending request.

Approval Path	Displays the path name that you are creating or updating. The path provides the sequence of approvers of a request, usually from a single reporting (or other) hierarchy.
Criteria	Click to access the Criteria Definition page where you can define user and field criteria along with monetary and application class criteria.
Step Source	Static: Select this source to indicate that you want the system to use the individual user-defined steps when it processes an approval. Dynamic: A dynamic path definition contains only one step. When begun, the single step definition could yield any number of instances in sequence. When using the Dynamic source, the system uses the user list on the step definition to initialize the steps in the path. The single step definition is repeatedly run, until the step's user list returns no more approvers. All these instances are queued in sequence.
Skip Prior Steps for Requestor	If one of the approvers in this path is also the requester, then select this option to have the system skip all steps in this path prior to that approver's step.

Timeout Options

The timeout options enable you to define the amount of elapsed time allowed for an approver to take action on a workflow step before the system escalates the step, and define what to do when an approver does not respond within the allowed time.

Options	Select the type of timeout option to define. Options are: Advance Approval: The workflow approval will move to the next approver in the chain after the number of days and hours you specify. Notify: A user will receive a notification after the specified period of time without approval or denial taking place. Reassign: The system automatically reassigns the work order to another designated approver in the same stage if approval or denial has not occurred within the designated period of time.
Hours	Enter the number of hours a transaction can remain at one workflow step before being escalated. This field is combined with number of days to determine the total time an approver has to take action on an approval request.
Days	Enter the number of days a transaction can remain at one workflow step before being escalated. This is the length of time an approver has to do something such as approve or deny a transaction.
Reassign To	If the timeout option is Reassign, specify the userID to whom you want to reassign the approval task.
User List	If the timeout option is Notify, specify the user list to which you want to send the notification.

Defining Approval Steps

Access the Step page to set up additional parameters for the step definition.

Step Number

Enter the number for this step. It's the sequence in which an approval is routed. Each step typically represents a routing to an approver. However, it is possible to route to multiple approvers or reviewers in a step as well.

Approver User List

Select the type of approver you want to use for this step based on the user list.

Approver Role Name

In addition to a user list, a role can be added to check for additional authorization checking. Select a role that specifies the authority that a user has. The approval workflow engine filters approvers returned by the user list for this role. It also enforces the role at the time the approver acts. If the role assignment changes, such as the approver is no longer in the role, the approver is blocked from acting on the work order.

All Approvers Required

Select to indicate that all approvers at this step are required to approve the work order at this step. You can select to have all approvers or some approvers approve the work order at this step.

Criteria

Click to access the Criteria Definition page where you can define field criteria along with monetary and application class criteria.

Some Approvers Required

Select to indicate that it's not required for all approvers to sign off on a work order. If you select this option, you can define the number of approvers required in the Number of Approvers Needed field.

Number of Approvers Needed

Enter the minimum number of approvers you want to sign off for a work order at this step. When an approval process is launched and this number can't be met, the system notifies the approval Admin Rolename.

Self Approval

Select to indicate that requesters can also approve their own work order. This only applies if the requester also appears as an approver in the step. You can establish criteria that control the requester's approval authority by using the Self-Approval Criteria link. If the associated criteria evaluate to true, then self-approval is acceptable. For example, you can place a limit on the dollar amount for the requester so that if the transaction is over that amount, the requester is not used as an approver.

If you select self approval and the criteria is not met, the approval workflow engine requires that there be at least one more step after this one in the path. This does not apply to ad hoc steps. Clearing the check box means that self-approval is never acceptable.

Note. If the criteria are not met, and there is no later step, the system inserts an additional step. This is then routed to the administrator.

Self-Approval Criteria

Click to access the Criteria Definition page where you can set up self-approval criteria for a user, including field criteria and monetary and application class criteria.

Reviewer User List

Select the type of reviewer you want to use for this step. You use a user list to map users to certain functional roles. The system then uses the list and its users to run automated business processes. The list defines the user sources who can be used in approval and review steps.

Authorizing Approvers

Access the Approval Authorization page, using the WM_WORK_ORDER approval process ID.

Use this page to define approvers and their authorization criteria for use in the work order approval process.

Approval Process ID	Select WM_WORK_ORDER.
Role Name	Select a role that you want authorized as an approver when this approval process is used for document approvals. You can select a role name or a user ID for each row, but not both.
User ID	Select a user whom you want authorized as an approver when this approval process is used for document approvals.
Criteria	Click to access the Criteria Definition page where you can set up approval criteria for each user or user role that you select.
Self-Approval Criteria	Click to access the Criteria Definition page, where you can define the conditions under which work order submitters can approve their own transactions. For example, you can define the greatest amount the submitter can self approve before additional approvals are required. The User Auto Approval check box setting on the Approval Process page enables self-approval. If self-approval is enabled, the system assumes that the work order submitter can approve a work order. If you establish criteria that control the submitter's approval authority, and that criteria is exceeded, the system does not include the submitter as an approver.

Modifying Approval Notification Options

Access the Approval Transaction Registry page using the WM_WORK_ORDER approval process ID.

The approval transaction registry definition is the metadata that describes the transaction make up to the work order approval workflow engine.

Note. To use the delivered work order approval workflow, modify only the notification options list in this section. The remaining fields should not be changed.

Notifications Options

Enable Notifications

Select the type of notifications to use for work order approvals. Options are:

Enable Email and Worklist: Select to use emails and worklist entries for notifications.

Email Notification Only: Select to use only emails.

Defining Generic Notification Templates

Access the Generic Template Definition page.

You use generic templates to establish common formats for ad hoc notifications.

Maintaining User List Definitions

Access the User List Definition page.

Use this page to define user sources for use with steps in the work order approval process. PeopleSoft delivers the following user lists for use with work order approvals: Work Order Original Requestor and Work Order Approver.

When you select a user list source type, you must also select a corresponding value. You can add a new user list or change a current list.

Note. You can select only one user list source for a user list.

Role	Select to use a role as the source for this user list. A role is a list of users who perform the same type of work, such as buyers or managers. Each role has a set of parameters that determine the limits what the roles can and cannot do in the organization and in the workflow process.
SQL Definition	Select to use a SQL definition as the source for this user list. Two SQL Objects are delivered, one for work order shop manager (WM_WO_SHOP_MGR), and one for the original requestor of the work order (WM_WO_WR_REQUESTOR).
Query	Select to use a query as the source for this user list. When a source is defined as a query, the system determines who should receive a work item based on the field values on the page that triggers the routing.
Application Class	Select to use an application class as the source for this user list. When you select to you an application class, the system passes in the originator of the transaction and then determines the approver for that originator. For subsequent approval steps, the system passes in the approver from the previous step.

Note. The SQL definition, query, and application class user list sources are dynamic and can use input values to help identify users.

Include Users as Input	When you select the check box, the system uses the originator of a transaction as the first step in each path. For subsequent steps in each path, the system uses the approver from the previous step.
Transaction Keys as Input	Select to have the system base the approval routing on transaction keys. Transaction keys are key fields in a database table. The system uses transaction record keys from the header record. For PeopleSoft Maintenance Management these are the Business Unit and Work Order ID fields.

Preview	Click to view how a workflow instance would function when it runs.
Approval Process Builder	Click to access a graphical tool that enables you to view each stage, path, and step of the approval process. Note. When you are viewing the graphic tool in the Approval Process Building page, if you elect to make changes the system will return you to the standard Approval Process Definition page.
Set ID	Identify the set ID for the workflow approval process.
Effective Date	Specify the date on which this approval process is effective and ready for system use. This applies to approval processes for a particular approval process ID and setID and includes PeopleSoft functionality associated with effective-dated entities. For instance, if multiple approval processes are active with the approval process ID, setID and effective date specification, then the system uses the latest active effective-dated process.
Status	Select the current state of this approval process. The values are: Active: Indicates the approval process is available for use. Inactive: Indicates the approval process is not available for use.
Admin Role (administrative role name)	Select the user list role to route the transaction to if an error occurs during the work order approval process. Note. The error conditions are no approvers or not enough approvers.
User Auto Approval	Select to enable the system to remember an approver’s action for this process. The next time this approval process is presented to the approver, the system automatically applies the approvers selections. The automatic application of steps in the process is left in place until you clear the User Auto Approval check box. This applies to the specific work order the approver had previously approved in this process only.
Route to Requester	Route to Requestor works in conjunction with the Self Approval flag. If the approver failed to meet the self approval criteria, the approval could still be routed if this check box is enabled. If the check box is not enabled and the approver fails to meet the self approval criteria, then the system routes the approval to the administrator.
Alert Criteria	Click to access the Criteria Definition page where you can define user and field criteria along with monetary and application class criteria for this stage. See Defining Approval Criteria.
Stage	Enter the sequence in which you want this stage of the approval acted upon. You can also enter a description for the stage in the Description field. A stage is a logical grouping within a process, such as commodity or fiscal approval. You can define a single stage or use multiple stages, in which case the stages execute in strict sequence. Before the second stage starts, the first stage must end. Each stage must be either at the header level or at the line level. This is the additional constraint on header- versus line-level approval configurations. A header-level stage acts on the single header. A line-level stage acts (simultaneously) on all the lines under the header. Note. For PeopleSoft Maintenance Management work orders, approval is done at the header for the entire work order, not for individual work order tasks, and only the header level is supported.
Level	Select Header. At a header-level stage, the system enables the same request (header) to be routed to two or more parallel paths. Line level approvals are not supported for work orders.
Approval Path	Enter a value that identifies this path. A path is a sequence of steps. Within a stage, paths execute in parallel with each path at the level from the stage to which it belongs. Path-entry criteria determine whether a path executes. If the system evaluates the criteria you enter for a path to be false then it bypasses that path. When a stage becomes active (approvers in the stage get pending work), all its contained paths become active simultaneously. All the paths of a stage queue work to approvers in parallel. The stage is complete only when all paths in it complete.
Source	Select the method by which steps are instantiated during the approval process. Values are: Static: Select this source to indicate that you want the system to use the individual user-defined steps when it processes an approval. Dynamic: A dynamic path definition contains only one step. When begun, the single step definition could yield any number of instances in sequence. When using the Dynamic source, the system uses the user list on the step definition to initialize the steps in the path. The single step definition is repeatedly run, until the step's user list returns no more approvers. All these instances are queued in sequence. User lists are associated with queries and classes using the User List Definition page. To access the page, select Set Up Financials/Supply Chain, Common Definition, Approvals, User List.
Path Details	Click to access the Path page where you can define path criteria and escalation parameters, such as whether or not to notify the requester's supervisor.
Criteria	Click to access the Criteria Definition page where you can define field criteria along with monetary and application class criteria. You can define criteria for the approval process using most records and fields in the database. The system uses these criteria as entry criteria for both the path and step.
Step	The sequence in which you want this step performed during the approval process. Use the arrow icons to move a step up or down in the sequence of steps.
Approver User List	Select the type of approver you want to use for this step. A user list is an entity which groups users in the system. Roles, queries and application classes are examples of user lists. The system then uses the list and its users to run automated business processes. The list defines the user sources who can be used in approval steps. When configuring approval workflows, business analysts use user lists to assign approval tasks to the approvers and reviewers who are to act on the request being considered for approval. The approval engine has two types of contextual information available to the user list definition: the previous approvers in the path, and the transaction (header or line) keys. The previous approver of the first step of a path is always the requester, regardless of which stage the path belongs to. In the case of SQL queries, the context is provided by bind values. The bind values are the prior approver (one per call, in case there are multiple prior approvers) and the keys of the header record. The key values are provided in the order in which they are defined in the corresponding record object.
Step Details	Click to access the Step page where you can define approver requirements, self approval details, and reviewers.

Step Number	Enter the number for this step. It's the sequence in which an approval is routed. Each step typically represents a routing to an approver. However, it is possible to route to multiple approvers or reviewers in a step as well.
Approver User List	Select the type of approver you want to use for this step based on the user list.
Approver Role Name	In addition to a user list, a role can be added to check for additional authorization checking. Select a role that specifies the authority that a user has. The approval workflow engine filters approvers returned by the user list for this role. It also enforces the role at the time the approver acts. If the role assignment changes, such as the approver is no longer in the role, the approver is blocked from acting on the work order.
All Approvers Required	Select to indicate that all approvers at this step are required to approve the work order at this step. You can select to have all approvers or some approvers approve the work order at this step.
Criteria	Click to access the Criteria Definition page where you can define field criteria along with monetary and application class criteria.
Some Approvers Required	Select to indicate that it's not required for all approvers to sign off on a work order. If you select this option, you can define the number of approvers required in the Number of Approvers Needed field.
Number of Approvers Needed	Enter the minimum number of approvers you want to sign off for a work order at this step. When an approval process is launched and this number can't be met, the system notifies the approval Admin Rolename.
Self Approval	Select to indicate that requesters can also approve their own work order. This only applies if the requester also appears as an approver in the step. You can establish criteria that control the requester's approval authority by using the Self-Approval Criteria link. If the associated criteria evaluate to true, then self-approval is acceptable. For example, you can place a limit on the dollar amount for the requester so that if the transaction is over that amount, the requester is not used as an approver. If you select self approval and the criteria is not met, the approval workflow engine requires that there be at least one more step after this one in the path. This does not apply to ad hoc steps. Clearing the check box means that self-approval is never acceptable. Note. If the criteria are not met, and there is no later step, the system inserts an additional step. This is then routed to the administrator.
Self-Approval Criteria	Click to access the Criteria Definition page where you can set up self-approval criteria for a user, including field criteria and monetary and application class criteria.
Reviewer User List	Select the type of reviewer you want to use for this step. You use a user list to map users to certain functional roles. The system then uses the list and its users to run automated business processes. The list defines the user sources who can be used in approval and review steps.