Using Workflow and Managing Approvals

This chapter provides overviews of the approval workflow engine, approval workflow, and approval workflow tasks and discusses how to:

Set up approval workflow process definitions.
Define the approval transaction registry.
Define notification templates for approval workflow.
Define users for approval workflow.
Define dynamic approvals.
Set up email collaboration.
Set up the notification and escalation manager.
Use the approval monitor.

Understanding the Approval Workflow Engine

Many daily tasks are part of a larger process that involves several steps and people working together. The term workflow refers to this process, which could encompass, for example, the approval of a requisition or a change request form. To facilitate this type of multiuser process, the PeopleSoft product can automatically trigger workflow notifications to inform the next approver in the process of work awaiting them.

A specialized designer is available to address workflow approvals. This designer enables you to configure approval workflows using existing components without writing code.

Three types of users come together to set up approvals. They include application developers, functional business analysts, and users, who include requesters, approvers, and reviewers. The approval workflow framework brings these roles together to define an approval process workflow.

Application developers set up workflow approvals using a transaction-definition component. Examples of a transaction might include a requisition or service order. Transactions are made up of an approval process, routing rules and steps, and a set of users who approve and review the transaction.

Using workflow approval processes, you can:

Approve or deny individual line items in a transaction, such as a change request.
Approve and deny multiple transactions one at a time.
Include multiple approvers for individual steps.
Assign additional approvers and reviewers during the approval process.
Escalate approvals.
Approve, deny, push back, and delegate approvals.
Reassign approval tasks to another approver.
Use Worklist and email notifications.

Understanding Approval Workflow

This section discusses:

The approval workflow process.
Header- and line-level approvals.
Approval flows.
Approval features.

The Approval Workflow Process

Approval workflows are triggered when requesters originate a transaction, such as a requisition, and a set of approvers carry out tasks related to the transaction. The PeopleSoft approval workflow process is a framework that enables three levels of users to develop, configure, and use transaction approvals that meet their organizational requirements. For example, the process of submitting a requisition and getting it approved requires defining who will approve the requisition, the order in which they will approve it, and how it will be routed to approvers.

In contrast to the standard PeopleSoft workflow, which requires advanced technical skills in PeopleSoft PeopleTools to create and maintain, approval workflow provides an alternative workflow that is much easier to create and maintain. For example, all of the steps in approval workflow are defined using PeopleSoft pages rather than underlying PeopleSoft PeopleCode, so functional users can design and maintain workflow using these online PeopleSoft pages instead of requiring technical developers to create workflow rules.

The following PeopleSoft products are delivered with integrated approval workflows:

PeopleSoft Supplier Contracts
PeopleSoft Promotions Management
PeopleSoft Expenses
PeopleSoft Strategic Sourcing
PeopleSoft eProcurement
PeopleSoft Services Procurement

To implement the approval workflow process, the framework for building and interpreting workflow approvals brings together these users:

Application developers

Application developers adapt applications for approval with minimal coding, using a defined setup process. Making this possible is the approval workflow engine, which provides a common implementation that other applications can use. Application developers integrate their applications with the approval workflow engine framework using the Register Transactions page, where they register an application with the engine and describe its components, event handler, and records. The register stores the approval process IDs that developers create for applications.

Note. The PeopleSoft product delivers the transaction registry for PeopleSoft Supplier Contracts, PeopleSoft Promotions Management, PeopleSoft Expenses, PeopleSoft Strategic Sourcing, PeopleSoft eProcurement, and PeopleSoft Services Procurement.

After an end user creates an application transaction and submits it for approval, the application hands the transaction over to the approval workflow engine, which finds the appropriate approval process definition and launches the approval workflow.
Functional business analysts

Functional business analysts design approval workflow for use with an application. This includes setting up stages, paths, steps, recipients, and notifications for each approval process ID. Analysts identify the application-supplied transaction definition on which to base approval process definitions. They use the Approval Process Definition page to define processes for approving transactions. These processes can be used repeatedly to guide transactions through their approval process.

Many businesses need different approval routings for different types of transactions. To support such variations, you can configure multiple approval process definitions for each transaction within an application. In addition to process IDs, approval process definitions are effective-dated. Each registered transaction can have multiple definitions. Each definition is effective-dated. The user also has the option to create a default definition in the event that no other definitions can be used.
End users

End users create transactions and then use an approval process with approvers and reviewers within an approval flow. Using this process, the different end users can approve or deny requests, monitor transaction statuses, and audit approvals.

Header- and Line-Level Approvals

Many PeopleSoft transactions have a top-level record (known as a header) with keys that uniquely identify a single transaction in an application. Then, these transactions typically have children records (line-level records) of this header record.

The approval workflow process uses an application’s header keys to correlate approval processes and application transactions. For example, when you open an application transaction, the approval workflow engine enables you to submit the request for approval only if you haven’t already submitted it. This check is possible because the system correlates the application header keys with the approval process instance keys.

When you need to track an approval status at a lower level within a transaction, an analyst can configure the approval process so that different line-items in the same request follow different routes. In such cases, the workflow approval engine splits the workflow into constituent line items, and enables analysts to configure the approval process so that different line items in the same request follow different routes. These lines of the workflow are still part of the same request, however, and should be tracked as such.

You can deny some lines of the requisition and approve others, making line-level approvals independent for each line. For example, a requisition can contain multiple lines, and you might want to use special approvers for certain catalog items, such as software or hardware. You can add specialized approvers to approve requisitions that are in their area of expertise.

An approval workflow might have mixed header and line-level approval routings. For example, department managers might exercise budgetary control over the request as a whole, while commodity approvers still examine only those line-items which fall within their expertise. Final approval requires both types of approvers to sign off on the requisition.

When a request is approved, the engine notifies the application, which then takes source end actions:

End actions.

An approval of one transaction often leads to the creation of another transaction, or triggers another business process. The approval workflow engine supports this trigger by providing a call-back mechanism for event notification. For example, when a requisition is approved, it can be sourced—an action follows final approval, which is the end action.
Line-level versus header-level end actions.

Use line-level approvals to make it possible for an action to be taken on different line items upon their approval, without waiting for the approval of other line items in the requisition. You can source line items as soon as they are approved.

This action is possible only if line-level approval routings are at the end of the process and require no further review. In this case, the application can act on the individual lines as they get approved. The approval workflow engine notifies the application of significant approval-related events.

Header actions allow the transaction lines to be grouped together and processed as one unit.

Approval Flows

After an approval process is defined, validated, and made active, the system can submit a transaction for approval. Each PeopleSoft application typically has a top-level database record that distinguishes one transaction from the next. For example, the eProcurement application's top-level record is REQ_HDR. These top-level records are called header records. When a transaction is submitted for approval, the approval workflow engine combines the approval process definition with the header record instance and line records, if line level approval is configured, to create a unique approval process instance. This approval process instance is routed from approver to approver, as configured in the approval process definition.

Approvals use two levels of processing: header and line. Business analysts set up the approval process definition that determines the flow of the approval at both levels. The approval process consists of:

Stages

A stage is one part of an approval process that can contain multiple parallel paths but must be at the same header or line record level. The system executes stages in sequence where one must complete before the next one begins. A stage can be at either a header level or at a line level. Stages at a line level make it possible for approvers to sign off separately on individual line items for a single transaction. The workflow engine sees each header and each line as individual pieces. A line is a child of the header. A header stage acts on the unique header while a line stage acts on each line. 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 determines whether or not a path executes for a given transaction or transaction line.
Steps

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

The system notifies approvers by using email, Worklist, or both, of pending approval steps, which can require one, all, or a fixed number of 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 to the next step. If the workflow has no further steps, it advances to the next stage.

Note. While the configuration may require multiple approvers to approve a step before it advances, any single approver can deny a step. The moment an approver denies a step, the transaction stops moving forward in the approval process. If the transaction is at a line level, other lines will continue to move forward. If the denial is at a header level, the approval process terminates, and the entire transaction is denied. However, PeopleSoft Expenses allows processing to continue.

This diagram illustrates how the approval process uses stages, paths, and steps for routing approvals:

The approval workflow

Approval Features

Using a combination of features, you can create rules for different types of approvals. This section discusses:

Ad hoc path approval
Ad hoc review
Self-approval
Route to requester
Skip prior pPath
Auto approval
Alternate approvers
Push back
Approval comments

Ad Hoc Path Approval

During the approval process, approvers can add other approvers or reviewers to the current or a later stage of the approval process. For example, if a buyer wants input from an inventory analyst, she can add the analyst as an approver. This action is called ad hoc approval, and it only applies to the approval instance in which the addition occurs and does not affect the underlying process definition used for other requests.

You can insert ad hoc approvers and reviewers in serial or parallel with existing approvers:

For serial approvals, each approval in the process is sequential.

Users can add approvers and reviewers only after the current pending step or later.
For parallel approvals, the sequence does not matter.

Users can insert an ad hoc step in an ad hoc path in any currently pending or subsequent stage.

You can add ad hoc approvers once the requisition is submitted. The approval workflow engine launches the previewed approval process instance if requested by the application developer’s code.

If you have an ad hoc approver user list defined in the transaction registry, only the users within that list can be added as an ad hoc approver or reviewer.

See Defining User Lists.

Ad Hoc Review

Ad hoc reviewers are users that an approver or requester would like to review a transaction. Ad hoc reviewers are notified and provided with a link in a Worklist entry or email to the transaction, if the process is so configured.

Self-Approval

A requester can also be an approver. If requesters approve their own transactions, it's called self-approval. A check box setting enables self-approval. If enabled, the requester’s approval is assumed, and the process continues. However, you can establish criteria that helps control the requester's approval authority. 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 self-approval is not enabled, then the requester can't serve as an approver. If the requester appears as an approver for any step, they are blocked from acting. If, because of this, the number of approvers that are available to act drops below the minimum, then an error is generated. The process is then routed to the administrator.

If self-approval is enabled, then the self-approval criteria must be specified. Then, if the requester appears as an approver, the criteria is evaluated. If the criteria are met, then the requester's approval is assumed and the minimum approvers for that step decrements by one.

When a requester is an approver, you can configure the path to skip the steps in that path prior to the requester's step.

Self-approval is configured at the step level.

Route to Requester

Route to requester is a feature that informs the system that an approval should be sent to a requester under certain circumstances:

If self-approval is set up, the criteria to trigger self-approval is not met, and route to requester is not selected, then the requester can't be included as part of the approval path.
If route to requester is selected and self-approval criteria is not met, then the requester is included as part of the approval path and the system notifies them of the pending approval.

For example, if a vice president orders items on behalf of a direct report at the supervisor level, the system will send a notification to the supervisor for whom the order was made. The supervisor remains part of the approval process.

Skip Prior Path

When skip prior to requester is enabled, the system begins the approval flow at whatever step in which the requester is an acknowledged approver.

For example, if a vice president orders supplies for herself, the system skips application approval steps leading up to the step for which the vice president is an acknowledged approver.

Auto Approval

When auto approval is enabled, the system remembers an approver’s action for that process at the header- or line-level, and applies the same action automatically for any subsequent appearance in the approval workflow routing.

For example, if the approver approves line one and the line appears again as a required approval for the specific approver, the approval is remembered for the line. This approval does not pertain to any other line, but header approvals do imply line approval for this feature.

Alternate Approvers

Alternate workflow approvers are users who are assigned to receive emails and Worklist notifications for the primary approver when the primary approver is not available. When you identify an alternate approver, you enter a date range during which you want the alternate to fill in. The system determines if the alternate is in place for the date range.

Note. Alternate users are defined in the User Profile. Navigate to PeopleTools, Security, User Profiles, User Profile.

Push Back

Push back takes a currently pending step out of pending status and requeues the previous step to its approvers. The meaning of push back is that the approver is questioning the prior step’s approval and is requesting clarification. Push back is only possible within a path, therefore, the first step of a path cannot push back.

Note. The push back feature ignores auto self-approval.

Approval Comments

Requesters can add comments to transactions, and approvers can associate their comments with the approval process rather than the request transaction directly. The approval workflow monitor provides a mechanism for associating comments with a particular approval process instance, which is tied to a particular application transaction. Approvers can view comments added by another approver, but they cannot change previous comments.

Understanding Approval Workflow Tasks

This section details the steps to implement and use approval workflow. It describes tasks that application developers, business analysts, and end users perform in conjunction with approval workflow.

To implement and use workflow:

Application developers register information with the approval workflow engine by using the Register Transactions page.

As part of defining the registry:
1. Application developers create a record and table in which to store cross-reference information and set up notification templates for events.
  
  This definition determines the pending approval workflow process and tells an application which transaction is being approved or denied.
2. Link the transaction component.
Functional business analysts define the approval process definition for an application transaction.

Essentially, analysts determine the approval transaction registry entry on which the process definition is to be based and then define the details of the process. The approval process definition includes definitions of stages, paths, steps, and criteria.
Requesters submit a transaction for approval.

This action launches the approval process. The approval workflow engine reads the approval process definition and queues the transaction for approvers.
The system queues an approval task to an approver or reviewer using email notification, Worklist entry, or both.

The URL encoded in the Worklist entry points to the corresponding approval component.
Approvers take actions on transactions.

When an error or violation of criteria or rules occurs during the approval process, the system notifies the administrator, who interacts to resolve the issue.

Note. The error conditions for static steps are no approvers or not enough approvers at a step.
Reviewers view the transaction.

Setting Up Approval Workflow Process Definitions

This section discusses how to:

Define approval workflow processes.
Define alert criteria.
Define criteria for approval workflow processes.
Define paths for approval workflow processes.
Define steps for approval workflow processes.

Pages Used to Set Up Approval Workflow Processes

Page Name	Object Name	Navigation	Usage
Setup Process Definitions	PTAF_PRCS_MAIN	Set Up Financials/Supply Chain, Common Definitions, Approvals, Setup Process Definitions For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Setup Process Definitions. For PeopleSoft Supplier Contract Management, use Supplier Contracts, Supplier Contracts Setup, Approvals, Setup Process Definitions.	Define workflow approval process stages.
Criteria Definition	PTAF_CRITERIA	Click the Definition Criteria link on the Setup Process Definitions page. Click the Criteria link from the Setup Process Definitions page in the Path section. Click the Criteria link from the Setup Process Definitions page in the Steps section.	Define criteria for workflow approvals.
Approval Path Definition	PTAF_PATH_SEC	Click the Path Details button or the Details link on the Setup Process Definitions page.	Set up workflow approval paths.
Approval Step Definition	PTAF_STEP_SEC	Click the Details link within the Steps group box on the Setup Process Definitions page.	Define steps for workflow approvals.

Defining Approval Workflow Processes

To set up approval processes, use the Approval Process component.

Access the Setup Process Definitions page.

Business analysts use this page to define an approval definition process. The process is made up of stages and their paths and steps. The approval steps that you place on the approval path represent the approval levels that are required for a transaction.

You can develop approval processes that:

Meet organizational or tiered approval limits.
Use alternate hierarchies, such as commodity approvers (procurement) and financial approvals (expenses) and so on.
Use multiple parallel tracks, such as procurement and inventory approvals at once.
Use staged tracks, such as first receiving commodity approval and afterward receiving financial approval.

Typical approval processes might include:

Employees or supervisors who can approve purchases up to a given amount.
Two different approvers for each step, where both approvers at a step must approve the request for it to advance to the next step.

Process ID	The Process ID created on the Register Transactions page. See Understanding the Approval Transaction Registry.
Definition ID	Enter any identification code that provides meaning to you. This identifier is used as a search field on the Monitor Approvals page. Note. When upgrading from a previous release, the SetID field is used for the Definition ID.
Definition 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. This criteria is used to determine which Definition ID is to be used to process the Approval. See Defining Definition Criteria.
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. This criteria can be evaluated by applications to highlight conditions of a transaction to be approved. For example, a one-time shipping address used only on this requisition. See Defining Alert Criteria.
Preview	Click this link to view what a workflow instance would look like if it were running.
Approval Process Viewer	Click this link to access a graphical tool, which 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 Builder page, if you elect to make changes the system will return you to the standard Approval Process Definition page.
Effective Date	Indicates the date on which this approval process became effective and ready for system use. This value applies to approval processes for a particular approval process ID and definition ID, and it includes PeopleSoft functionality associated with effective-dated entities. For instance, if multiple approval processes are active with the approval process ID, definition ID, and effective-date specification, then the system uses the latest active effective-dated process.
Admin Role (administrative role )	Select the user list role used by workflow to route the transaction to all users filling that role in case of an error during approval processing. Note. The error conditions are no approvers or not enough approvers. See Defining User Lists.
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. A transaction that has started with a specific definition continues using that definition, even if the status is Inactive.
Priority	Select to sort the definitions in the order that the Definition Criteria should be evaluated. The Definition with the highest priority and that matches the definition criteria is used to process the transaction. Priority 1 is the highest. Multiple Definition ID's can have the same priority. Note. Multiple Definition ID’s with the same priority may result in inconsistent behavior, in the event that multiple definition ID’s match.
Default Process Definition	Select to indicate that the system should use this process definition as the default when no other definition ID matches the criteria entered.
Take Action on Line Completion	Select to allow each line to continue to the next step of the approval process, with out waiting for other lines within the transaction to complete. This setting applies to approval processes that have a line-level stage at the end of the process. The system supports line-by-line sourcing only when the last stage is at the line level. This setting assumes that the line-level stage is the last stage of the approval process.
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 approver's selections. The automatic application of steps in the process is left in place until you clear the User Auto Approval check box. This setting applies to the specific line or header the approver had previously approved in this process only. A header approval implies line approvals for all lines.
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 selected. If the check box is not selected and the approver fails to meet the self-approval criteria, then the system routes the approval to the administrator.

Stages

Stage Number

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.

Level

Select the level at which you want approvals to be processed. All paths within the stage are at the same level as the stage itself. Available values are:

Header: At a header-level stage, the system allows the approvals to act on the transaction as a whole

Line: Line-level stages can have multiple paths with selection criteria that distinguish the line-item’s content, such as software line items going to software approvers. Line-level stages allow each line to route differently, if appropriate.

See Understanding the Approval Workflow Engine.

Paths

Description	Enter a description that identifies this path. A path is a sequence of steps. Examples of paths might include a hardware path where approval steps are defined for when hardware items are in a requisition. Another example could be a department path where a requisition requires approval up a department hierarchy. Within a stage, paths execute in parallel with each path at the level from the stage to which it belongs. Path-entry criteria determines whether a path executes for a transaction header or line. For example, for a line-level stage, each line in the transaction is presented to each path; the path criteria decides whether or not that path is triggered for that line. If the system evaluates the criteria you enter for a path to be false for a header or line, then it bypasses the path for that header or line. 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. Note. User lists are associated with roles, queries, and classes using the User List Definition page. To access the page, select Set Up Financials/Supply Chain, Common Definitions, Approvals, User List Definition. See Defining User Lists.
Path Details	Click to access the Approval Path Definition 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 path's 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.

Steps

Approver User List

Select the approver list that you want to use for this step. A user list is an entity that 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 in 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 multiple prior approvers exist) 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.

See Defining User Lists.

Step Details

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

Criteria

Click to access the step's 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.

Defining Definition Criteria

Access the Criteria Definition page.

This page works similar to the other Criteria Definition pages that are used for paths and steps, however this criteria is used to determine which Definition ID is to be used to process the Approval.

Defining Alert Criteria

Access the Criteria Definition page.

This page works similar to the other Criteria Definition pages that are used for paths and steps, with two differences:

The description field is the actual alert text that appears on the approval page.
The criteria determines if an alert should appear on the approval page, as opposed to routing a line or header for approval.

Defining Criteria for Approval Workflow Processes

Access the Criteria Definition page.

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

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

Criteria Type

Select one of these options:

Always True informs the system to trigger this workflow approval process. No criteria is needed. The system will only follow paths that evaluate as true.
Application Class requires you to 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.
User Entered requires you 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 to indicate that all criteria defined on the Criteria Definition page must be met in order to trigger the workflow to evaluate as true.

User Entered Criteria

Use this section to define additional criteria for the approval.

Description

Enter purpose of the alert.

For example, if you are using a one-time ship-to address, create a description that indicates that a one-time ship-to address is attached to the requisition.

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 you want to use in the approval process.

Record Name	Select a record that you want to use in defining approval criteria. For example, if you are indicating a one-time address, identify PO_ADDR_REQ_VW as the record.
Field Name	Select a field 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 Is Not Blank 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.
Value	Use the two Value fields to define a range upon which you want the operator criteria to evaluate. The second value is only used when the Criteria Operator evaluates using Between.

Monetary Criteria

Use this section to establish approval criteria for requisition amounts. The system uses the values you define to determine the routing for approving the requisition. 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 requisition to the minimum amount required to trigger the step. Note. If this approval process ID is used to trigger workflow for changes in amounts within requisitions, you need to use PV_CHGRST_AMTVW.
Amount Field	Select the field within the amount record to be used when comparing the requisition to the minimum amount required to trigger the step. The system uses the value 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 requisition in order to trigger the step. The system identifies all lines in the requisition 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 requisition total is higher than this minimum amount, the criteria is met. If no amount is specified, zero is considered the minimum. Note. If you use the Criteria Operator with a value of Between, a second Amount field becomes active.
Currency Code	Select the monetary unit 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

Use this section to assign application packages as criteria for the approval process definition. When you define a class, the system uses it along with other criteria you enter to process the approval.

Root Package ID	Select the primary application package. This selection is the parent class for other packages or for child application classes.
Application Class Path	Select a path that describes a specific class within the root package.

Defining Paths for Approval Workflow Processes

Access the Approval Path Definition 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.

Criteria	Click to access the Criteria Definition page where you can define user and field criteria along with monetary and application class criteria.
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.
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. See Defining User Lists.
Notify Admin on No Approvers notify administrator on no approvers	Select to indicate that the administrator is to be notified if the system does not find an approver for the path. This option is only available when the Step Source is Dynamic. Note. This is the default behavior for static paths.
Skip Prior Steps for Requester	Select to indicate that if one of the approvers in this path is also the requester, then the system is to skip all steps in this path prior to that approver's step.

Timeout Options

Escalate Option	Advanced Approval: Skip the current approver. Notify Participant: Sends an email, or whatever notification is defined in the transaction registry, to the individual. Reassign Approval: Reassigns to an user ID or a user list. Note. If you select Advanced Approval and defined a User List a notification is sent to the user list members. See Defining User Lists.
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 you have selected Reassign as the option, you can enter a user name or a specific user list. Note. A user list will reassign to the first user in the list that does not match the current user. See Defining User Lists.
User List	Select the list of users the workflow should be routed to. See Defining User Lists.

Defining Steps for Approval Workflow Processes

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

Criteria	Click to access the Criteria Definition page, where you can define field criteria along with monetary and application class criteria.
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.
Step Number	Displays the sequence number in which the approval is routed. Each step typically represents a routing to an approver. However, it is possible to route to multiple approvers or reviewers within a step.
Approver User List	Select the type of approver you want to use for this step based on the user list. See Defining User Lists.
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 requisition.
All Approvers Required	Select to indicate that all approvers at this step are required to approve the transaction at this step. You can select to have all approvers or some approvers approve the transaction at this step.
Some Approvers Required	Select to indicate that it's not required for all approvers to sign off on a transaction. If you select this option, you can define the number of approvers required in the Number of Approvers Needed field. Note. After the number is met, the approval advances to the next step.
Number of Approvers Needed	Enter the minimum number of approvers you want to sign off for a requisition 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 requisition. This setting only applies if the requester also appears as an approver in the step. You can establish criteria that controls 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 is not met and no later step exists, the system inserts an additional step. This selection is then routed to the administrator.
Reviewer User List	Select the type of reviewer you want to use for this step. 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. See Defining User Lists.

See Also

Approval Features

Maintaining System Users and Roles

PeopleSoft Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Workflow Technology, “User List Roles”

Defining the Approval Transaction Registry

This section provides an overview of the approval transaction registry, lists prerequisites, and discusses how to:

Register approval transactions.
Configure approval transactions.

Understanding the Approval Transaction Registry

The approval transaction registry is the interface application that developers use to register an application with the approval workflow engine. Transactions that require approvals are candidates for being linked to approval workflow engine. You use the Register Transactions page to link the components, event handler, records, and classes that you created into the approval process for an application transaction, such as a requisition or purchase order. Application developers register the main records and components that make up the transaction, then functional business analysts select the approval transaction on which to base the approval process definition.

Note. Any PeopleSoft delivered approvals will already have the Approval Transaction Registry populated. No additional configuration is typically needed.

Prerequisites

Before defining the transaction registry:

Create a Transaction Handler Application class that extends an approved event handler class delivered by approval workflow.
Create notification templates for the events, which include approval and denial for header and line levels.
Create transaction data sources, as needed.
Create views on transaction tables that will serve as criteria sources.
Create a view to serve as a source for ad hoc users.
Create a view to serve as a source for approver contact information.

Pages Used to Define the Approval Transaction Registry

Page Name	Object Name	Navigation	Usage
Register Transactions	PTAF_TXN	Set Up Financials/Supply Chain, Common Definitions, Approvals, Register Transactions For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Register Transactions.	Register the approval transaction. The transaction definition is the metadata that describes the transaction setup to the approval workflow engine.
Configure Transactions	PTAF_TXN_NOTIFY	Set Up Financials/Supply Chain, Common Definitions, Approvals, Configure Transactions For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Configure Transactions .	Use the Configuration Options page to configure how the system uses the particular implementation of approval triggers.

See Also

PeopleSoft Enterprise PeopleTools 8.48 PeopleBook: PeopleCode Developer's Guide

Registering Approval Transactions

Access the Register Transactions page.

Application developers use this page to register a PeopleSoft application, such as eProcurement or Service Procurement, with the approval workflow engine. Using the page, you can define how the system interacts with portions of the application that you have defined for approvals. The transaction definition is the metadata which describes the transaction make up to the workflow approval engine. In some cases, you might add a transaction to enhance an existing transaction or make changes to a transaction.

Use this page to define:

Worklist approvals.
Approval event handler class.
Transaction approval levels.
Email notifications.
Ad hoc approver class logic.

Approval Process ID

Enter a name the system uses to track this approval workflow process for a transaction. You can also enter a description for the approval process.

Object Owner ID

Select the PeopleSoft application to which this object belongs.

Cross Reference Table

Select the table used to manages application specific transaction records and associate them with the approval process run time instances. Each time a request launches an approval process, the system tracks the process by the header and line-level records of the application. To relate the approval process instance to the transaction instance, the cross-reference table holds the correspondence.

For a given application transaction record, this cross-reference information helps you determine the pending approval workflow process and to define to the application which transaction is being approved or denied.

Application developers must create a record containing the applications keys, and include an approval workflow engine-supplied subrecord. Developers must also build the underlying table.

Notification Options

Identify whether you will be using email or worklist notificatication, or both.

Enable Notifications	Determine what type of notifications your company will use. The options include: Disable Email and Worklist Email Notification Only Enable Email and Worklist Worklist Notification Only
Notification Strategy	It allows the email to be processed immediately(Online Processing)or offline(Offline Processing) through NEM (Notification and Escalation Manager.)
Use Email Approvals	Defines that you are going to use email approvals with workflow.
Form Generator Package Root	This package root reads the threads provided by the Form Generator Class, and creates a form from an existing email collaboration definition.
Form Generator Class Path	Calls the From Generator Class which receives a list of threads to be approved and a language code. This class returns a runtime class, which will add the appropriate recipients and send the emails.

Default Approval Component

Identifies the default component that users should go to when selecting a worklist entry.

Menu Name	Select the menu name that contains the component you want to register for the Worklist.
Approval Component	Select the component on which the approval is going to be based.

Approval Event Handler Class

Use this section to define the application class used to monitor events for this transaction. Each time an event occurs, the approval workflow engine notifies the application. For applications to receive the notifications, application developers must extend the event handler class, ApprovalEventHandler.

When a transaction results in an action from the approval workflow engine, the event handler class you specify determines how to proceed with the transaction.

The event handler base class defines the handler methods that you can override by extending classes. The extending class must have a no-argument constructor, since the system instantiates the class with no arguments.

This table explains the various event handler methods for which the system passes arguments to provide the specific context for each event, and gives examples of how an application, in this case PeopleSoft eProcurement, may act:

Event	Parameters	Possible Application Actions
PROCESS_LAUNCHED	Header record Approval Process Instance	Disable edits of the application transaction. Display status information.
HEADER_DENIED	Header record	Delete transaction. Disable resubmission. Log the event on the transaction, possibly highlighting previous denial if the system allows resubmission.
LINE_DENIED	Line-level record	Deduct the line amount from the header, and delete or otherwise deactivate the line item.
HEADER_APPROVED	Header record	Source the transaction if it’s a requisition. Reimburse the employee if it’s an expense report.
LINE_APPROVED	Line level record	Source the line item if it's configured for sourcing.
PROCESS_TERMINATED	Header record	Log the event on the application, possibly highlighting changes since the previous submission. This might be useful for approvers who acted on the previous submission of this request.
ALL_LINES_PROCESSED	Header record	Note. The system calls this method only if the last stage is at the line-level, and the analyst has configured the process to trigger LINE_APPROVED end calls as individual lines are approved. The action the system takes depends on how the application developer defines the line sourcing. If the lines are sourced as they are approved, then nothing has to be done when all the lines are processed. This event is distinct from HEADER_APPROVED, and having a distinct notification simplifies the process.

Root Package ID	Select the parent application class through which events are exposed. This defines the action to take based on events.
Path	Select a path that uses a specific class within the root package.

See PeopleSoft Enterprise PeopleTools 8.48 PeopleBook: PeopleCode Developer's Guide

Approval Status Monitor

Use this section to control how the system processes ad hoc approvers. any approver can add or remove ad hoc approvers.

Adhoc Package	Select the ad hoc application class package that you want to use for ad hoc approvals.
Adhoc Class	Select the ad hoc application class path. Adding approvers and reviewers is handled by the class you define here. If no class is specified, then the system default class is used. If the transaction has further restrictions an application developer needs to create a class that will be defined here.
Thread Package	The package here defines how the transaction details are displayed in the system in the status monitor. Behind the scene approvals are define with a sequence number. this allows for a user friends display.
Thread Class	Enter the specific class within the thread description package and the worklist description that sets the display details.

Transaction Approval Levels

Use this section to define if the transaction is to be approved at the header or line level and what level the application supports.

Level	Select Header or Line, which determines the levels that are enabled by the application for approvals. The first row will always be the header level.
Record (Table) Name	Select the database table that represents this transaction level.
Level Record Key Field Label IDs	Use this section to identify the label IDs that are used when viewing the Monitor Approvals page. All key Field Names appear for each Record (Table) Name that is listed.
Field Label ID	Select a Field Label ID, which appears on the Monitor Approvals page.

Configuring Approval Transactions

Access the Configure Transactions page.

Use this page to select and define elements that determine what triggers a notification, who receives the notification, and the content of the notification. Notifications are mapped to work with the approval transaction registry and include menus and components and SQL definitions. The events for which the system sends notifications include:

Launch of the approval process on a transaction.
Queue of approval step to an approver.
Queue of a review step to a reviewer.
Denial of a line or header.
Approval of a line or header.
Completion of the approval process.

Recipients of notifications include requesters, approvers, and reviewers, who can receive their notifications through either Worklist entries or email notification. When using email notifications, business analysts must create email templates.

Ad Hoc Approver Options

Approver User Info View

Provides details about which view a user sees when using the approval monitor.

Note. Data in this view dictates what is displayed in the approver links.

Ad Hoc User List

This is a filter used to display only a list of users who can be ad hoc approvers.

Notification Options

Email Approval User List

Specify exactly which users should be allowed to do their approval by using email.

Note. If the user receiving the notification also falls into the email approval user list, then they receive an email approval rather than a standard email notification.

Delivery Method

Define whether you wish the users to receive their email approvals as text within the email, or as attachments.

Perform Sent-To Security Check

Selecting this check box informs the system that you want it to verify the security of the person the notification is sent to.

Note. This security check is only performed on new approvals.

User Utilities

User Utilities are the mechanism that the user changes to modify the behavior of delegation and reassignment.

User Utilities Package	Select the parent application class through which alternate users are selected.
User Utilities Path	Select a path that uses a specific class within the root package.

Events

Use the events section to define event parameters to trigger workflow notification.

Level	Select Header or Line to determine the level at which you want a notification sent for an event. For each of these events to be notified, you must select the level of the transaction.
Event	Select the event for which you want to send a notification. The approver is always notified of an event. The requester and the system administrator is notified when an error occurs. Event values include: Ad Hoc Delete Ad Hoc Insert Hold Step Locked Out On Error On Escalate On Final Approval On Final Denial On Process Launch On Reactivate On Reassign On Step Complete On Terminate Processing Complete Request Information Request Information Added Route for Approval Route for Review Note. Lock Out, On Error, On Escalate, On Process Launch, On Terminate, and Processing Complete are for header level only.
Menu Name	Select the menu name that contains the component you want the notification recipient to link to. This identifies where the person should go upon notification. If you do not enter values, the recipient is sent to the same menu and component that is defined for the Worklist Approval component.
Approval Component	Select the component you want to make available to the notification recipient.
Page Name	The page defined is the page approvers are redirected to from the URL sent within the email notification.
Menu Action	This is the action of the page users see when directed to the page from the URL sent within the email notification.
SQL Object Identifier (structured query language object identifier)	Select the SQL definition identifier you want to use to get content for the email. The SQL must accept bind inputs equal to the number of keys at the notification level. For example, header or line keys.

Notifications

Use the Notifications section to define who to notify and how to notify them in addition to the defaults determined in the Events section of this page.

Participant	Define the user who is notified when this event takes place. Admin Approver Delegate Approver: the approver that the approval was originally assigned to. Delegate Requestor: the person who created the request for someone else. Dynamic Proxy Approver: the approver who performed the actual approval. Proxy Requestor: the person who requested the transaction to be created. Requester Reviewers User List
Channel	Defines how the participant will be notified. Both Email None User Worklist Note. Routing preferences can also be set up in PeopleTools, Security, User Profiles, Workflow. From there you have two options. You can select Worklist User and or Email User.
User List	Select either Dynamic or User List as the Participant. The option becomes active when you select one of these values.
Template Name	Select the generic template you want to use for the email content of this notification. You define the contents of the email using the Generic Template page. To access the page, select Set Up Financials/Supply Chain, Common Definitions, Approvals, Generic Templates.
Menu Name, Approval Comment, Page Name, Menu Action, and SQL Object Identifier	All of these fields have the same definition as the corresponding fields in the Events section of this page.
Number of Hours	Enter a number that determines how many hours between notifications.
Max Notification	Enter a number that determines the maximum number of notifications sent. If the approver does not take action, an escalation is sent to the administrator.

Defining Notification Templates for Approval Workflow

This section discusses how to enter generic template definitions.

Pages Used to Define Notification Templates for Approval Workflow

Page Name	Object Name	Navigation	Usage
Generic Template Definition	WL_TEMPLATE_GEN	Set Up Financials/Supply Chain, Common Definitions, Approvals, Generic Templates For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Email Notification Templates. For PeopleSoft Supplier Contract Management, use Supplier Contracts, Supplier Contracts Setup, Approvals, Generic Templates.	Enter generic template definitions.
URL Maintenance	URL_TABLE	PeopleTools, Utilities, Administration, URLs	Use this page to identify the URL that the notification process places within the email. The user then uses this URL to navigate back into their system to perform the required task. Note. An example of the format to use is http://servername/psp/employeeportaldomain/.

Page Name

Object Name

Navigation

Usage

Generic Template Definition

WL_TEMPLATE_GEN

Set Up Financials/Supply Chain, Common Definitions, Approvals, Generic Templates
For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Email Notification Templates.
For PeopleSoft Supplier Contract Management, use Supplier Contracts, Supplier Contracts Setup, Approvals, Generic Templates.

Enter generic template definitions.

URL Maintenance

URL_TABLE

PeopleTools, Utilities, Administration, URLs

Use this page to identify the URL that the notification process places within the email. The user then uses this URL to navigate back into their system to perform the required task.

Note. An example of the format to use is http://servername/psp/employeeportaldomain/.

Entering Generic Template Definitions

Access the Generic Template Definition page.

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

For approvals, the first bind variable is used to store the URL that appears in the email.

See Also

PeopleSoft Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Workflow Technology, “Using Notification Templates”

Defining Users for Approval Workflow

This section discusses how to:

Attach workflow roles to users.
Define workflow for user profiles.
Define user lists.

Pages Used to Define Users for Approval Workflow

Page Name	Object Name	Navigation	Usage
User Profiles - Roles	USER_ROLES	PeopleTools, Security, User Profiles, User Profiles Select the Roles tab. For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Workflow Roles.	Attach workflow roles to users.
User Profiles - Workflow	USER_WORKFLOW	PeopleTool, Security, User Profiles, User Profiles Select the Workflow tab. For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Set Supervisors.	Define workflow for user profiles.
User List Definition	PTAF_USER_LIST	Set Up Financials/Supply Chain, Common Definitions, Approvals, Maintain User Lists For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, User List Definition. For PeopleSoft Supplier Contract Management, use Supplier Contracts, Supplier Contracts Setup, Approvals, Maintain User Lists.	Define user lists.

Attaching Workflow Roles to Users

Access the User Profiles - Roles page.

Use this page to attach workflow roles to users. A role is a class of users who perform the same type of work, such as clerks, buyers, or managers. A role describes how people fit into workflow.

Role user IDs determine how to route Worklist items to users and how to track the roles that users play in the workflow.

Role Name	Select a role to assign to this user. Role users are the people who participate in automated business processes.
Dynamic	Appears if the definition of this role is dynamic. This value is driven by PeopleSoft PeopleCode. Dynamic users can obtain membership in a role programmatically. You can run a batch process that executes predefined role rules and assigns roles to user profiles according to these rules. This approach is called dynamic membership, and users who become role users of a particular role programmatically are dynamic role users. Static role users, on the other hand, obtain their membership through an administrator adding a role to their user profile manually.
Route Control	Select to access the User Route Control Profiles page, where you can select a route control profile for the workflow. The PeopleSoft Workflow Administrator enables you to define route controls. For example, suppose you want to route requisitions to different buyers, depending on which vendor supplies the ordered items, which business unit is requesting the items, and which department needs the items. You can define a route control for each factor—vendor ID, business unit, and department—and specify a range of values for each buyer. Note. Not used with eProcurement Approval Workflow.
View Definition	Select to access the Roles - General page, where you can change the role name definition. You can also view the user ID of the role member to ensure that you selected the appropriate definition for inclusion in the role.

See Also

PeopleSoft Enterprise PeopleTools 8.48 PeopleBook: Security Administration, “Administering User Profiles”

Defining Workflow for User Profiles

Access the User Profiles - Workflow page.

Use this page to define alternate users who are part of the workflow process. You can define alternate users to handle approvals during the absence of the primary approver and supervisor.

Alternate User ID	Select a user to receive Worklist items when this user ID is temporarily unavailable. The system automatically forwards new work items for whoever is assigned as the current role user to the alternate role user. The system doesn’t reassign items already in the user’s Worklist.
From Date and To Date	Enter a date range when the current user ID is not going to be available. The system uses these values to forward routings to the alternate user.
Supervising User ID	Select the user ID of this user’s supervisor. The system uses this value when forwarding information to the user’s supervisor and uses the PERSONAL_DATA record to determine the supervisor.
Worklist User	Select to indicate that this role user can receive approval routings. Clear the check box if the user is not a PeopleSoft user. You can select Worklist User, Email User, or both.
Email User	Select to specify that this role user can receive email. Clear the check box if email is not available.
Reassign Work To	Select to indicate that you want to send Worklist items to another user. After selecting the check box, select the user ID. When you save the page, the system removes the Worklist items from the current user's list and places them in the new user's list.

Defining User Lists

Access the User List Definition page.

Use this page to define user sources for use with steps in the approval process. The PeopleSoft product delivers a set of default user list roles corresponding to the roles within an organization.

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 only select one user list source for a user list.

Note. The SQL Definition, Query, and Application Class user list sources are dynamic, and can use input values to help identify users.

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 of the role in the organization and in the workflow process.
SQL Definition (structured query language definition)	Select to use an SQL definition as the source for this user list.
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 an application class, the system passes the originator of the transaction and then determines the approver for that originator. For subsequent approval steps, the system passes the approver from the previous step.
Include Users as Input	Select to indicate that 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. System actions depend on the approval level at which a user list is being used. If the approval is at the header level, the system uses transaction record keys from the header record.

See Also

PeopleSoft Enterprise PeopleTools 8.48 PeopleBook: PeopleCode Developer's Guide

Defining Dynamic Approvals

This section provides overviews of dynamic approval authorizations and approval authorizations and discusses how to:

Define user lists for dynamic authorizations.
Set up approval authorizations.
Define dynamic approval paths.

Understanding Dynamic Paths

To use dynamic approvals, create one approval step that determines a list of approvers without setting up every step individually within the path.

Workflow processes are defined in stages, paths, and steps. The system looks at the stage to determine if the trigger for the workflow is recognized at the header or line level. Within each stage, there is a minimum requirement of one path. The path contains steps, which define the workflow triggers and the action to take if the criteria is met. Without dynamic paths, the administrator creates a step for every possible approver. With dynamic workflow, the administrator creates a single path where the system users a user list for the approval hierarchy.

Note. When self-approval is used and the requisition creator is on the list of authorized approvers, that role is counted as one approval.

See Also

Defining User Lists

Understanding Dynamic Approval Authorizations

PeopleSoft applications use workflow to configure approval paths in two manners. The first configuration is to define every approval in step-by-step fashion. The second manner is to create dynamic approvals. Dynamic approvals enable you to create a single step that systematically identifies every potential approver, searches to find out if that approver has enough authority to complete the approval, and creates a visual path for users to view of all necessary approvers in the process. You can configure a dynamic path allowing supervisor roles to approve or deny a transaction, and stop the approval path when the system has determined that all criteria has been satisfied. The administrator creates a user list that the system uses to select the appropriate supervisory approvers for a transaction and then checks for authorization. The dynamic path takes the prior approver into consideration.

To configure the dynamic approval authorization, the administrator must:

Define user lists.
Create an approver authorization.
Define a dynamic approval path.

Two keys to creating approval authorizations for dynamic paths are the system’s ability to:

Check authorizations.
Skip unauthorized users.

The system looks at the user list and the approval authorization to determine which users are required to complete the authorization. The system displays the non-required users as a skipped step instead of a pending step in the event that Skip Unauthorized is selected.

This diagram illustrates an example of a workflow routing setup for the standard method and a workflow routing that skips unauthorized users:

Example of Skip Approval scenario

In the example, the criteria for the workflow approval path is set up for Chris Baker to have approval authority for less than 1,000.00 USD, Patrick Sanchez to have authority for less than 5,000.00 USD, VP to have approval for less than 25,000.00 USD, and CEO to have approval for a requisition equal to or more than 25,000.00 USD.

Kelly Jones creates a requisition for 10,000.00 USD.

If the system is not set up to skip unauthorized users, the system displays Chris Baker, Patrick Sanchez, and the VP as pending steps in the approval path.

If the system is set up to skip unauthorized users, the system displays the approval path with the VP as the only listed approver, and will display Chris Baker and Patrick Sanchez as skipped.

See Also

Defining User Lists

Understanding Approval Authorizations

You can identify the approval authorization by role or user in conjunction with a dynamic step. To accomplish this, the approval workflow engine selects the appropriate supervisory approver from the user list and verifies that the approver meets the criteria for authorization.

You establish approval authorizations for each transaction. The authorization can accommodate approvals by role or user ID.

You can set authorization across Definition IDs, which are defined on the Setup Process Definition page.

For each authorization, the system checks the specific user ID to see if that individual can authorize the transaction. If found, it checks the authorization criteria. If criteria are met, the user has authorization.

If no authorization is found for a specific user ID, then the system looks for role-based authorizations using the approval hierarchy.

For approval hierarchy, the system first looks for authorization by Definition ID. If no authorization is found, the system then seeks authorization for rows without a Definition ID. If no authorization approval criteria is matched, the system process is deemed Not Authorized.

You can establish dynamic authorizations for either the header or line level, but not both.

When workflow is initiated for a change order or requisition, the system compares the approval authorization data to the user list to verify the approval process. To verify the approval, the system:

Checks the user list and assigns the first approver to the first user that is returned.
Looks at the roles that are established for the user ID.
Identifies the approval limits that are set for that user ID.
Routes the requisition status to the first approver if the amount is satisfied for the requisition and the approver list is complete.
Continues to look for additional approvers until all conditions are met.
Routes the approval to the administrator if the approver criteria is never met.

See Also

Defining User Lists

Pages Used to Define Dynamic Approvals

Page Name	Object Name	Navigation	Usage
Approval Authorization	PTAF_AUTH	Set Up Financials/Supply Chain, Common Definitions, Approvals, Authorize Approvals For PeopleSoft eProcurement, use eProcurement Administer Procurement, Maintain Workflow, Approval Authorization.	Authorize roles and approvers for dynamic paths.
Setup Process Definitions	PTAF_PRCS_MAIN	Set Up Financials/Supply Chain, Common Definitions, Approvals, Setup Process Definitions For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Setup Process Definitions.	Define workflow approval process stages.
Criteria Definition	PTAF_CRITERIA	Click the Alert Criteria link on the Setup Process Definitions page.	Define criteria for workflow approvals.
Approval Path Definition	PTAF_PATH_SEC	Click the Path Details button or the Details link on the Setup Process Definitions page.	Set up workflow approval paths.
Roles - General	ROLEDEFN	PeopleTools, Security, Permissions and Roles, Roles For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain System Users and Roles, Roles.	Set up roles for workflow.
Approval Step Definition	PTAF_STEP_SEC	Click the Details link within the Steps section on the Setup Process Definitions page.	Define steps for workflow approvals.
User List Definition	PTAF_USER_LIST	Set Up Financials/Supply Chain, Common Definitions, Approvals, Maintain User Lists For PeopleSoft eProcurement, use eProcurement Administer Procurement, Maintain Workflow, User List Definition.	Set up list of users for workflow approval.
User Profile	USER_GENERAL	PeopleTools, Security, User Profiles, User Profiles	Set up user IDs and assign roles.

Defining User Lists for Dynamic Authorizations

Access the User List Definition page.

The approval workflow engine delivers a default user list SAC_AW_SUPERVISOR that addresses the most common approval scenario of routing an approval to a supervisor. If the requester is an end user, his immediate supervisor can’t authorize more than 5,000.00 USD, and the requisition is for 6,000.00 USD, then the requisition moves to the next level supervisor. The user ID for the direct supervisor is listed on the user profile.

Note. To enable the Supervisor by User Id approval routing, you must have a supervisor assigned to your user ID on the user profile page.

See Also

Defining User Lists

Setting Up Approval Authorizations

Access the Approval Authorization page.

If you don’t specify a Definition ID, the authorization is generic. To create an approval authorization for specific definition IDs, you must add a line for each Definition ID.

Note. If you activate self-approval on the Approval Authorization page, it replaces the self-approval on static path steps.

Defining Dynamic Approval Paths

Access the Approval Path Definition page.

Step Source	Select Dynamic for a dynamic approval path.
Notify Admin on No ApproversNotify administrator on no approvers	Select to indicate that the administrator is to be notified if the system does not find an approver for the path. This option is only available when the Step Source is Dynamic.
Skip Prior Steps for Requester	Select to indicate that if one of the approvers in this path is also the requester, then the system is to skip all steps in the path prior to that approver's step.
Check Authorization	Select to enable the approval authorization.
Skip Unauthorized Users	Select to enable the approval process to skip users within the user list if the system determines that they can't satisfy all of the criteria for approval.

Note. When creating criteria within the path that will trigger the workflow engine to activate, be certain that you set up the final approver as Greater Than so that no gaps occur.

Setting Up Email Collaboration

This section provides an overview of email collaboration and discusses how to set up email collaboration.

Understanding Email Collaboration

The email collaboration framework allows applications to send, receive, and process emails with interactive content. You can send an HTML form to a user, and they do not need to log into their system to perform tasks.

These steps describe the flow of email collaboration:

A system event triggers PeopleSoft PeopleCode, which creates a collaborative email and sends it to a user.
The user who receives the email takes appropriate action and clicks Submit..
The user's submission is sent to an email account that is designated for holding responses.
An application engine program runs on a configured interval, polling the repository for new emails.

It processes the emails and publishes them as service operations.
The service operation runs, allowing the implementing application to process the data in a known and supported format.

Pages Used to Set Up Email Collaboration

Page Name	Object Name	Navigation	Usage
Node Definitions	IB_NODE	PeopleTools, Integration Broker, Integration Setup, Nodes	Set up the PT_EMC_GETMAIL node.
Node Properties	IB_NODEPROP	PeopleTools, Integration Broker, Integration Setup, Nodes Select the Properties link.	Use this page to modify the node properties, which is required for email collaboration to function.
Form Element Designer	PTAF_EMC_ELEMENTS	Set up Financials/Supply Chain, Common Definitions, Email Collaborations, Form Element Designer	Define metadata used as system data when you deliver an email collaboration. Note. The grid is automatically populated with all the fields in your message definition, excluding those that are part of the EMC required records and any that are marked as include in your message definition.
Form Layout Designer	PTAF_EMC_LAYOUT	Set up Financials/Supply Chain, Common Definitions, Email Collaboration, Form Layout Designer	Defines the layout of the email.
Register Transactions	PTAF_TXN	Set Up Financials/Supply Chain, Common Definitions, Approvals, Register Transactions For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Register Transactions.	Set up the registry to use collaborative emails as part of notifications. See Registering Approval Transactions.
Configure Transactions	PTAF_TXN_NOTIFY	Set Up Financials/Supply Chain, Common Definitions, Approvals, Configure Transactions For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain Workflow, Configure Transactions.	Configure how a specific approval process uses email notification options. See Configuring Approval Transactions.
Recurrence Definition	PRCSRECURDEFN	PeopleTools, Process Scheduler, Recurrences	Defines how often you want the process scheduler to run processes.
Application Engine Request	AE_REQUEST	PeopleTools, Application Engine, Request AE	Set up the Request AE for PTAF_EMC.
Email Addresses	USER_EMAIL	PeopleTools, Security, User Profile, User Profile Select the Edit Email Addresses link. For PeopleSoft eProcurement, use eProcurement, Administer Procurement, Maintain System Users and Roles, User Profile. Select the Edit Email Addresses link from the General tab.	Modify email addresses.

Setting Up Email Collaboration

To set up email collaboration:

On the Node Definitions page, activate the PT_EMC_GETMAIL node.
On the Node Properties page, enter the email address of the email repository in the EMC_REPOSITORY_EMAILADDRESS property.
(Optional) On the Node Properties page, enter appropriate values for EMC_BCC_LIST and EMC_CC_LIST properties to automatically send a copy of all collaborative emails to the address specified.
On the Recurrence Definition page, specify an interval for the process scheduler recurrence.
On the Application Engine Request page, create a request for the application engine to run the process PTAF_EMC.

Specify the process schedule server and the recurrence.
On the Configure Transactions page, enter values for the notification options.

See Defining the Approval Transaction Registry.

Setting Up the Notification and Escalation Manager

This section provides an overview of notification and escalation and discusses how to:

Associate events to a server.
Set up an escalation event.
Set up a notification and escalation manager (NEM).

Understanding Notification and Escalation

NEM is a mechanism used to process notifications and escalations on a specified interval.

For example, escalations are used when an approver has not responded within a specified time period to a transaction that is pending approval. You can specify the time period (timeout) and you can specify alternate approvers to whom to notify and escalate the approval for further action. Timeout options are defined on the Approval Path Definition page.

Pages Used to Set Up the Notification and Escalation Manager

Page Name	Object Name	Navigation	Usage
Event Types	PTAF_NEM_EVENTS	Set up Financials/Supply Chain, Common Definitions, Notifications and Escalations, Event Types	Associate events to a server.
Setup Event	PTAF_NEM_SETUP	Set up Financials/Supply Chain, Common Definitions, Notifications and Escalations, Setup Event	Set up an escalation event and define the evaluation and action details.
Schedule JobSet Definitions	SCHDLDEFN	PeopleTools, Process Scheduler, Schedule JobSet Definitions	Set up a NEM to define the job to run, and how often you want it to run.

Associating Events to a Server

Access the Event Type page.

Event Type	Select an event type. The system is delivered with these values: ESCALATION_EVENT, APPROVALACTIVITYEMAIL, and RECEIPT_NOTIFICATION_EVENT.
Server Name	Select the server on which to run the escalations.

See Setting Up and Using the Message Dashboard.

Setting Up an Escalation Event

Access the Setup Event page.

Event Type	The server information that was entered on the Event Type page.
Event Types Description	The value entered in the Description field on the Events Type page.
Active	Select to enable the escalation process.
Recurrence	Enter a time interval at which to run the evaluation process.
Repeat Time	Enter a time period to limit the number of times the action step is run.
Evaluation Type	Select a method for evaluation. Possible values are: PeopleCode: Select if you are using a custom application package or class written using PeopleSoft Application Designer. Query Object: Select if you are using a query set up using the PeopleSoft Query Manager tool. SQL View: Select if you are using a record object created using the PeopleSoft Application Designer. Note. For escalations, the evaluation type should be SQL View.
Action Type	Select an action: PeopleCode: Select if you are using a custom application package or class written using the PeopleSoft Application Designer. Email: Enter an email address and notification template. Note. For escalations, the action type should be PeopleCode.
Package	Select the application package that contains the escalation utility. Note. For escalations, the package should be PTAF_CORE .
Class	For escalations, select Escalator.

Setting Up a NEM

Access the Schedule JobSet Definitions page.

Schedule Name	Select SAC_NEM for the notification and escalation manager.
Job Name	Select NEM_MAIN for the notification and escalation manager.
Status	Select Active for the notification and escalation manager.
Run Control ID	Enter the run control that has the run configuration desired.
Recurrence Name	Enter a value that specifies how often the process runs.

Using the Approval Monitor

This section provides overviews of the approval monitor and approval reassignment and discusses how to:

Utilize the approval monitor.
Utilize the approval monitor for a specific approval process.

Understanding the Approval Monitor

The approval monitor gives administrators a view into all approvals to which they have access, as well as the ability to take necessary actions on pending approvals. Actions available for the administrator are:

Reassignment	Allows the system administrator to reassign pending approvals to a new approver based on search criteria.
Approve	Allows the administrator to act on behalf of the assigned approver. The approval is initiated for a specific user, wherever that user may be pending within a specific transaction. Once the administrator takes action, the approval resumes the approval process.
Denial	Allows the administrator to act on behalf of the assigned approver. The denial is initiated for a specific user, wherever that user may be pending within a specific transaction.
Ad Hoc	Allows the administrator to add a reviewer or approver to a specific transaction.

Understanding Approval Reassignment

You can reassign pending tasks to another approver, or an administrator can reassign all tasks that belong to a specific approver to another approver. Use reassignment in the following situations:

The approver chooses to redirect the task to another approver, thus delegating a specific task (step) to another approver.
The administrator decides to reassign all pending tasks within a step that belong to an approver to another approver.

This reassignment usually occurs when an approver is unexpectedly absent and the administrator reassigns all pending tasks to another.

When you redirect a workflow task to another approver, you can modify the approval process map.

Note. The approval workflow engine is set up for administrative reassignment and escalations only.

Pages Used to Utilize the Approval Monitor

Page Name	Object Name	Navigation	Usage
Monitor Approvals	PTAF_ADM_MON_SRC	Set Up Financials/Supply Chain, Common Definitions, Approvals, Monitor Approvals	Use the Monitor Approvals page as a system administrator to search approval processes and perform mass reassignments.
Monitor Approvals	PTAF_ADM_MON_ACT	Set Up Financials/Supply Chain, Common Definitions, Approvals, Monitor Approvals Select the link for the approval step you want to modify.	Use this page to perform an action on a specific approval process.

Page Name

Object Name

Navigation

Usage

Monitor Approvals

PTAF_ADM_MON_SRC

Set Up Financials/Supply Chain, Common Definitions, Approvals, Monitor Approvals

Use the Monitor Approvals page as a system administrator to search approval processes and perform mass reassignments.

Monitor Approvals

PTAF_ADM_MON_ACT

Set Up Financials/Supply Chain, Common Definitions, Approvals, Monitor Approvals

Select the link for the approval step you want to modify.

Use this page to perform an action on a specific approval process.

Utilizing the Approval Monitor

Access the Monitor Approvals page for a view of the approval process.

Approval Process

Select an approval process. The list of approval processes available is determined by the administrator role associated with the approval process definition. If a user is associated with the role specified in the Admin. Role field on the Setup Process Definitions page, they can view, act on, or both for that process ID within the approval monitor.

See Defining Roles, Actions, and User Lists.

Definition ID

Select the process definition that is determined on the Setup Process Definition page.

Header Status

Select a status in this field to display the selected status. Choices are:

Approved

Complete

Denied

Hard Deny

Initial

Not Active

Pending

Pending Denial

Suspended/Pending Denial

Terminated

Approver

Select an approver. You can view or take action on approval processes for a specific approver.

Approver Status

Select a status from those available. This field is only available when a specific approver is selected in the Approver field. The statuses available for selection are based on the statuses of that specific approver in the cross-reference table associated with the approval process ID.

Originator

Select the user who entered the transaction that started the approval process.

Utilizing the Approval Monitor for a Specific Approval Process

Access the Monitor Approvals page to take action on a specific approval process.

Approver

Select an approver. All approvers associated with pending steps within the approval process are listed.

Comment

Enter text to appear under the approval graphic in the Approval Comment History section.

Reassign To

Select an approver to whom to reassign all pending steps within the approval process.

Allow Self-Approval

Select to enable self-approval. When it is enabled, the approval is assumed and the process continues.

Allow Auto Approval

Select to enable auto-approval. When it is enabled, the system remembers an approver’s action for that process at the header or line level, and applies the same action automatically for any subsequent appearance in the approval workflow routing.

Approve

Click the Approve button to act on behalf of the selected approver. This action applies to all tasks pending for the approver selected within the context of the approval process.

Deny

Click the Deny button to act on behalf of the selected approver. This action will apply to all tasks pending for the approver selected within the context of the approval process.

Pushback

Click to requeue the previous step to its approver. This button is only available at a step that is greater than one.

For example, a transaction has three approvers. The first approver has approved the transaction, therefore, the transaction is pending at step two. The administrator needs additional information from the requester and, therefore, pushes the transaction back to the requester.

Restart

Click to restart a pending transaction to all approvers in the approval path. This button is only available when the transaction is pending.

Resubmit

Click to resubmit a completed transaction to all approvers in the approval path. This button is only available when the transaction is complete. The transaction can only be resubmitted in its current state and cannot be modified before resubmitting for approval.

See Understanding Approval Workflow.

Reassigning Tasks Assigned to You

To reassign your tasks to another approver, select a step assigned to you as an approver and request that the step be reassigned to an alternate. You must have an administrator role to perform this task.

The approval workflow engine (AWE) reassigns that step to the newly appointed approver, and deletes the original approver’s worklist entry. The system creates a new worklist entry for the new approver, and notifies the new approver.

The AWE adds a comment to the approval thread to log the reassignment.

Reassigning Tasks as an Administrator

To reassign a specific approver’s pending tasks to another approver:

Filter the display to present pending approval processes for the specific approver.
Indicate the steps to be reassigned and the users affected.

The system submits a request to the AWE to reassign all of the pending steps.

Once you have reassigned the pending tasks to a new approver, the approval path is updated and the approval transaction is routed to the new approver.

Note. You can create reassignments through the user profile. However, workflow reassignments through the user profile don't alter the actual approval process. Reassigning using the Monitor Approvals component performs the reassignment and creates the worklist for the new user.

The administrator can also take action instead of reassigning.

Comment History

Expand the Comment History section to view the previous workflow streams. This section is available when the system has resubmitted the transaction due to a change in the transaction.

For example, a requisition is approved by two out of three approvers. Then the requisition is changed before the third approver sees it. The system resubmits the requisition and begins the approval path from the beginning. The Comment History section retains the original stream, indicating that the first two approvers had approved the original requisition.

Approval Process	Select an approval process. The list of approval processes available is determined by the administrator role associated with the approval process definition. If a user is associated with the role specified in the Admin. Role field on the Setup Process Definitions page, they can view, act on, or both for that process ID within the approval monitor. See Defining Roles, Actions, and User Lists.
Definition ID	Select the process definition that is determined on the Setup Process Definition page.
Header Status	Select a status in this field to display the selected status. Choices are: Approved Complete Denied Hard Deny Initial Not Active Pending Pending Denial Suspended/Pending Denial Terminated
Approver	Select an approver. You can view or take action on approval processes for a specific approver.
Approver Status	Select a status from those available. This field is only available when a specific approver is selected in the Approver field. The statuses available for selection are based on the statuses of that specific approver in the cross-reference table associated with the approval process ID.
Originator	Select the user who entered the transaction that started the approval process.

Approver	Select an approver. All approvers associated with pending steps within the approval process are listed.
Comment	Enter text to appear under the approval graphic in the Approval Comment History section.
Reassign To	Select an approver to whom to reassign all pending steps within the approval process.
Allow Self-Approval	Select to enable self-approval. When it is enabled, the approval is assumed and the process continues.
Allow Auto Approval	Select to enable auto-approval. When it is enabled, the system remembers an approver’s action for that process at the header or line level, and applies the same action automatically for any subsequent appearance in the approval workflow routing.
Approve	Click the Approve button to act on behalf of the selected approver. This action applies to all tasks pending for the approver selected within the context of the approval process.
Deny	Click the Deny button to act on behalf of the selected approver. This action will apply to all tasks pending for the approver selected within the context of the approval process.
Pushback	Click to requeue the previous step to its approver. This button is only available at a step that is greater than one. For example, a transaction has three approvers. The first approver has approved the transaction, therefore, the transaction is pending at step two. The administrator needs additional information from the requester and, therefore, pushes the transaction back to the requester.
Restart	Click to restart a pending transaction to all approvers in the approval path. This button is only available when the transaction is pending.
Resubmit	Click to resubmit a completed transaction to all approvers in the approval path. This button is only available when the transaction is complete. The transaction can only be resubmitted in its current state and cannot be modified before resubmitting for approval.