Setting Up the Approval Framework

This chapter provides an overview of approval processing and discusses how to:

Set up user lists.
Set up approval process definitions.
Set up the transaction registry.
Set up approver authorization.

Understanding the Approval Framework

This section discusses:

Approval workflow in Enterprise Learning Management.
Delivered approval process definitions.
Approval process definition setup.

Approval Workflow in Enterprise Learning Management

Many PeopleSoft applications use workflow to automate the movement of tasks and information from one role or user to another:

From employee to manager.
Between managers.
From managers to administrators.

Although workflow can be used to route different kinds of tasks and information between users, most workflow in Enterprise Learning Management involves approval processing. For example, when a student selects a course from the catalog that requires approval, his/her enrollment request may go to a manager, an administrator, or a user outside the management hierarchy for approval. Workflow for enrollment and registration approvals is managed by the Approvals Framework—a specialized interface that enables you to set up approval process definitions using existing components without writing code. These process definitions specify workflow routing rules and steps, and the users who will review and approve each step in a transaction.

Using workflow approval processes, you can:

Approve, deny, push back, or delegate individual items in a transaction.
Approve and deny multiple transactions at a single time.
Define multiple approvers for individual transactions.
Assign additional approvers and reviewers during the approval process.
Escalate approvals.
Send worklist and email notifications.

Delivered Approval Process Definitions

Enterprise Learning Management delivers approval process definitions as sample data that you can use to trigger approval workflow when a learner makes an enrollment request, a program registration request, or requests supplemental learning. Based on these sample process definitions, the system routes learning requests to managers, administrators, and other system users for approval, and sends workflow items or emails to designated users notifying them of their role in the approval chain.

All of the delivered approval process definitions follow the same general logic and incorporate the same functionality that was delivered in Enterprise Learning Management 8.81:

When an activity, program, or supplemental learning request triggers approval processing, there is one “initial” approver and one or more subsequent approvers.
If the learner has no “initial” approver (a manager, for example), the learner's request is auto-approved.
The initial approver of a learning request can take one of two actions: approve or deny.

Subsequent approvers of a learning request can take one of three actions: approve, deny, or push back.

Subsequent approvers might be senior managers or others in the management hierarchy, or users who are outside the management hierarchy, such as individuals in the finance or legal department.

This table lists the delivered approval process definitions:

Approval Process Definition	Description
ACT BOTH-SPECIAL	Activity enrollment — both internal and external learners require special approval.
ACT INT-MGR EXT-NONE	Activity enrollment — internal learners require manager approval, no approval is required for external learners.
ACT INT-MGR EXT-PAYADMIN	Activity enrollment — internal learners require manager approval, external learners require approval from the payment administrator.
ACT INT-MGR EXT-SPECIAL	Activity enrollment — internal learners require manager approval, external learners require approval from a special approver.
ACT INT-NONE EXT-PAYADMIN	Activity enrollment — internal learners require no approval, external learners require approval from the payment administrator.
ACT INT-NONE EXT-SPECIAL	Activity enrollment — internal learners require no approval, external learners require approval from a special approver.
ACT INT-SPECIAL EXT-NONE	Activity enrollment — internal learners require approval from a special approver, no approval is required for external learners.
ACT INT-SPECIAL EXT-PAYADMIN	Activity enrollment — internal learners require approval from a special approver, external learners require approval from the payment administrator.
ACTIVITY ENROLLMENT	Approval path is learner's manager, payment administrator, then special approver, as appropriate.
PRG BOTH-SPECIAL	Program enrollment — both internal and external learners require special approval.
PRG INT-MGR EXT-NONE	Program enrollment — internal learners require manager approval, no approval is required for external learners.
PRG INT-MGR EXT-PAYADMIN	Program enrollment — internal learners require manager approval, external learners require approval from the payment administrator.
PRG INT-MGR EXT-SPECIAL	Program enrollment — internal learners require manager approval, external learners require approval from a special approver.
PRG INT-NONE EXT-PAYADMIN	Program enrollment — internal learners require no approval, external learners require approval from the payment administrator.
PRG INT-NONE EXT-SPECIAL	Program enrollment — internal learners require no approval, external learners require approval from a special approver.
PRG INT-SPECIAL EXT-NONE	Program enrollment — internal learners require approval from a special approver, no approval is required for external learners.
PRG INT-SPECIAL EXT-PAYADMIN	Program enrollment — internal learners require approval from a special approver, external learners require approval from the payment administrator.
PROGRAM REGISTRATION	Approval path is learner's manager, payment administrator, then special approver, as appropriate.
SUP BOTH-LEARNER SELECTED	Supplemental learning enrollment — both internal and external learners require approval from a learner selected approver.
SUP INT-MGR EXT-NONE	Supplemental learning enrollment — internal learners require manager approval, no approval is required for external learners.
SUP INT-MGR EXT-SPECIAL	Supplemental learning enrollment — internal learners require manager approval, external learners require approval from a special approver.
SUP INT-NONE EXT-SPECIAL	Supplemental learning enrollment — internal learners require no approval, external learners require approval from a special approver.
SUP INT-SPECIAL EXT-NONE	Supplemental learning enrollment — internal learners require approval from a special approver, no approval is required for external learners.
SUPPLEMENTAL LEARNING	Approval path is learner's manager, payment administrator, then special approver, as appropriate.

Note. These definitions are delivered as sample data and can be modified based on your own approval requirements.

Note. This list includes approval processes created for enrollment in activities, programs, and supplemental learning, as well as a number of more specific approval process definitions delivered for backwards compatibility.

Note. We discuss the three Enterprise Learning Management transactions that use approval processing—activity enrollment, program registration, and supplemental learning requests—elsewhere in this PeopleBook.

Approval Process Definition Setup

This section discusses:

General approval process setup.
Enterprise Learning Management approval process setup.

General Approval Process Setup

The setup pages described in this section are the basis for the approval processes delivered with many PeopleSoft applications. Within Enterprise Learning Management, these pages are used to define the “sample” approval processes for enrollment, registration, and supplemental learning requests. You can use them to modify these delivered sample processes or to create your own approval definitions.

Important! To use the sample approval processes created by PeopleSoft, new install customers must import them into their production environments by running the LMAP01.DMS script with the LMAP01.DAT file.

To modify delivered approval processes or define new process definitions:

Access the User List Definition page to define the list of users who can approve enrollment or registration requests.

For example, you can define user lists to include everyone in a specific role such as the manager or learning administrator role, or select users who meet the criteria specified in a SQL statement or query.
Access the Process component (SAC_AW_PRCS) and define the following:
1. The sequence of stages, paths, and steps that make up a process definition.
  
  A stage consists of one or more approval paths and their associated steps or actions. A path represents a specific sequence of approval steps, and each step represents an approver or approval action within the sequence.
  
  When you define a process definition, you associate approval steps with user lists (defined in step 1) to control who can approve a learning request.
2. The criteria that must be satisfied before the system sends users along a specific stage, path, or step in the approval process.
  
  You can associate criteria with a stage as well as with specific paths or steps that make up a stage when you define path and step details (see steps c and d below).
  
  For example, you can define criteria to activate an approval path when the cost of enrollment is greater than 100 USD but less than 300 USD. And you can activate a different path when the cost is greater than 300 USD.
3. Path details.
  
  This includes:
  
  1) Defining the criteria that the system uses to determine when to follow a specific path.
  
  2) Providing instruction for escalating approval steps to a different user when the designated approver fails to approve, deny, or push back an approval request.
4. Step details.
  
  This includes:
  
  1) Defining the users who are authorized to approve learning requests at each step in the path.
  
  2) Defining the users who are authorized to review approval steps.
  
  3) Defining the criteria that the system uses to determine when to activate a step.
  
  4) Defining when a requestor who is also an approver can approve his/her own training requests.
Register the transaction that triggers approval processing on the Approval Transaction Registry page.

The approval transaction registry is the interface you use to register a transaction with the approval workflow engine.
Define workflow notification options on the Notification page.
Define approval authorization by role or user on the Approval Authorization page.

Enterprise Learning Approval Process Setup

In Enterprise Learning Management you associate approval process definitions with catalog items, activities, programs, and supplemental learning types using the Approval Type field on the Maintain Items (LM_CI_LA_CMP), Maintain Activities (LM_ACT), Maintain Programs (LM_PROG), and Define Supplemental Learning (LM_ADHC_SETUP) components. When a learner, manager or administrator submits an enrollment request for an activity, program, or supplemental learning that requires approval, the system initiates the sequence of paths and steps contained in that process definition.

This section describes how to configure the system to use the sample approval process definitions as well as any process definitions that you create yourself.

Note. Enrollment, program registration, and supplemental learning requests do not automatically trigger approval workflow. You must specify approval requirements when you define Catalog Items, Programs, and Supplemental Learning templates on the Maintain Items (LM_CI_LA_CMP), Maintain Activities (LM_ACT), Maintain Programs (LM_PROG), and Define Supplemental Learning (LM_ADHC_SETUP) components.

To configure approvals in Enterprise Learning Management:

Select the Activity Enrollment and Supplemental Learning check boxes on the Enrollment Defaults page of the Install Defaults component (LM_IN_DFLT_CMP) to enable approval processing for enrollment and supplemental learning requests.

Note. If you do not select these options, the Approval Type field on the Item Details, Activity Details, and Supplemental Learning Request pages is still available. However, when an enrollment or supplemental learning request is submitted, the system bypasses the approval framework and the enrollment/supplemental learning is immediately confirmed.

See Defining Default Processing Rules and Options.
Select the Program Registration check box on the Program Defaults page of the Install Defaults component (LM_IN_DFLT_CMP) to enable approval processing for program registration requests.

Note. If you do not select this option , the Approval Type field on the Program Details page is still available. However, when a registration request is submitted, the system bypasses the approval framework and the registration is immediately confirmed.

See Defining Installation Defaults for Programs.
Select a SETID for approvals on the Basic Data page of the Learning Environment component (LM_LE_CMP).

The SETID determines which approval process definitions are available in the Approval Type field on the Item Details, Activity Details, Program Details, and Supplemental Learning Details pages.

Note. When you create approval process definitions, you tie these definitions to specific SETIDs. The SETID is then used to control which of these definitions are available within a specific learning environment.

See Defining Learning Environments.
Associate approval process definitions with catalog items, activities, programs, and supplemental learning types using Approval Type field on the following components:
- Maintain Items (LM_CI_LA_CMP)
- Maintain Activities (LM_ACT)
- Maintain Programs (LM_PROG)
- Define Supplemental Learning (LM_ADHC_SETUP)
When a learner enrolls in and activity, registers for a program, or submits a supplemental learning request , the system uses the associated approval process to route the approval requests to the required approvers.

See Assigning Objectives to Catalog Items and Programs.

See Defining Activity Details.

See Building Learner Groups.

See Setting Up Supplemental Learning Types.

Note. You define approval process definitions using the Process component (SAC_AW_PRCS).

Note. We discuss the pages used to enroll in activities, programs, and supplemental learning, and the pages used by managers and administrators to review and approve enrollment requests, in the chapter on self-service transactions and the chapter on enrolling and registering in learning activities and programs.

Setting Up User Lists

To define user lists, use the User List (SAC_USER_LIST) component.

This section discusses how to set up user lists.

Page Used to Set Up User Lists

Page Name	Object Name	Navigation	Usage
User List Definition	SAC_USER_LIST	Set Up ELM, Approvals, User List, User List Definition	Create and maintain user-list definitions.

Setting Up User Lists

Access the User List Definition page.

Use this page to define user sources for use with stages, paths, and steps in the approval process. PeopleSoft 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.

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 managers or administrators. Each role has a set of parameters that limit what the roles can and cannot do in the organization and in the workflow process. Note. The SQL definition, Query, and Application Class user list sources are dynamic, and can use input values to help identify users.
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 worklist 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 in the originator of the transaction and then determines the approver for that originator. For subsequent approval steps, the system passes in the approver from the previous step.
Include Users as Input	When you select this check box, the system uses the originator of a transaction as the first step in each path. For subsequent steps in each path, the system uses the approver from the previous step.
Transaction Keys as Input	Select to have the system base the approval routing on transaction keys. Transaction keys are key fields in a database table. 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.

Note. Review your PeopleTools documentation for more information about defining roles, SQL definitions, queries, and application classes.

Setting Up Approval Process Definitions

To define approval processes, use the Process (SAC_AW_PRCS) component.

This section provides an overview of approval process definitions, and discusses how to:

Define an approval process definition.
Define criteria for approvals.
Define path details.
Define step details.

Understanding Approval Process Definitions

Approval process definitions define the steps that must be followed to approve a transaction, and the approvers for each step.

Pages Used to Set Up Approval Process Definitions

Page Name	Object Name	Navigation	Usage
Approval Process Definition	SAC_AW_PRCS_MAIN	Set Up ELM, Approvals, Process, Approval Process Definition	Define the sequence of stages, paths, and steps that make up an approval process.
Criteria Definition	SAC_CRITERIA	Click the Alert Criteria link on the Approval Process Definition page. Click the Criteria link on the Approval Process Definition page in the Paths section. Click the Criteria link on the Approval Process Definition page in the Steps section.	Define criteria for activating a stage, path, or step.
Path	SAC_AW_PATH_SEC	Click the Path Details link on the Approval Process Definition page.	Define the details of a specific approval path.
Step	SAC_AW_STEP_SEC	Click the Step Details link on the Approval Process Definition page.	Define the details of a specific step in an approval path.

Defining an Approval Process Definition

Access the Approval Process Definition page.

SetID

Select a SetID.

Learning Environments uses SetIDs to limit access to approval processes.

Admin Role (administrative role)

Select the user list role used 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.

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 in the approval process.

User Auto Approval

A user may participate more than once in the same approval process. Select User Auto Approval to enable the system to remember a user's initial approval actions in an approval process. The next time this user is asked to take an action in the process, the system automatically reproduces the user's earlier actions. The system continues to repeat these actions until you clear the User Auto Approval check box.

Stages

Stage Number

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

Paths

Approval Path	Enter a value that identifies this path. A path is a sequence of steps in the approval process. Within a stage, paths execute in parallel with other paths in the same stage. 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 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 of its 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 are complete.
Step Source	Select the method by which steps are instantiated during the approval process. Valid values are: Static: Select this source to indicate that you want the system to use individual user-defined steps when it processes an approval. Dynamic: A dynamic path definition contains only one step. When begun, the single step definition can yield any number of instances in sequence. When using a 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 of these instances are queued in sequence.
Path Details	Click to access the Path page, where you can define path criteria and escalation parameters, such as when to notify a designated approver's supervisor if the approver does not approve, deny, or push back a learning request within a reasonable time frame.
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 path using most records and fields in the database.

Steps

Step Number	Enter the sequence in which you want this step performed during the approval process.
Approver User List	Select the approver user list you want to use for this step. A user list is an entity which groups users in the system. The list defines the user sources that can be used in approval steps. Roles, queries and application classes are examples of user lists. 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. Note. The approval engine has two types of contextual information available to the user list definition: the previous approvers in the path, and the transaction (header or line) keys. The previous approver of the first step of a path is always the requester, regardless of which stage the path belongs to. In the case of SQL queries, the contextual information is provided by bind values. The bind values are the prior approver (one per call, in case there are multiple prior approvers), and the keys of the header record. The key values are provided in the order in which they are defined in the corresponding record object.
Step Details	Click to access the Step page, where you can define approver requirements, self-approval details, and reviewers.
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 step using most records and fields in the database.

Defining Criteria for Approvals

Access the Criteria Definition page.

Use this page to define the criteria the system evaluates to determine whether to trigger an approval stage, path, or step. You can define criteria consisting of a field with a logical operator and a value or definitions consisting of an application class that takes in transaction data.

Criteria enable you to change routing paths, steps, and other elements of the approval process using transaction-specific information. In order to set the context for the criteria, the engine provides the transaction keys as bind values.

All Criteria Needed to Satisfy	This check box indicates that all criteria defined on the Criteria Definition page must be satisfied in order to trigger the workflow stage, path, or step.
Description	Describe the criteria you are defining.

Field Criteria

Use this section to select records and fields containing the data or types of data to be evaluated by the criteria definition.

Record Name	Select a record containing the data to evaluate.
Field Name	Select the field containing the data to evaluate.
Criteria Operator	Determines how the system evaluates the values in the Value fields. Valid options are: Between: Only values between the two values you enter as criteria trigger the approval stage, path, or step. Equals: Only values equal to the values you enter as criteria trigger the approval stage, path, or step. Greater Than: Only values greater than the values you enter as criteria trigger the approval stage, path, or step. Is Blank Is Not Blank Less Than: Only values that are less than the values you enter as criteria trigger the approval stage, path, or step. Not Equal To: Only values that are greater than or less than the values you enter as criteria trigger the approval stage, path, or step.
Value	Use this field to define the value that the operator criteria evaluates. The second Value field is used only when the Criteria Operator is Between.

Monetary Criteria

Use this section to establish approval criteria using monetary amounts. The system uses these monetary values in conjunction with the Operator field to determine whether to run an approval stage or a step or path within the stage.

Amount Record	Select the record name to use when comparing training costs to the amount required to trigger the stage, path, or step.
Amount Field	Select the field within the amount record to use when comparing training costs to the amount required to trigger the stage, path, or step.
Currency Field	Select the currency field that corresponds to the currency code in the Currency Code field.
Operator	Select an operator. The operator determines how the system evaluates the values in the Amount fields. Options include Between, Greater Than, and Less Than.
Amount	Use the Amount fields to define an amount to use with the Operator field. Enter the amount required to trigger the stage, path, or step. If actual training costs are greater than, less than, or between the specified amounts—depending on the operator— the criteria are satisfied. Note. If you set the criteria Operator to Between, a second Amount field becomes active.
Currency Code	Select the currency to use with the amount.
Rate Type	Select the rate type that the system uses to arrive at the currency value.

Application Class Criteria

Use this section to specify application classes as criteria for the approval process definition. When you define a class, the system uses it along with other criteria you enter to determine when to activate the approval process.

Root Package ID	Select the primary application package. This 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 Path Details

Access the Path page.

Use this page to tell the system how to handle an approval request when an approver takes too long to approve or deny a pending request.

Approval Path	Displays the path name that you are creating or updating. The path lays out the sequence of approvers of a request, usually from a single reporting (or other) hierarchy.
Criteria	Click to access the Criteria Definition page where you can define user and field criteria along with monetary and application class criteria.
Step Source	Static: Select this source to indicate that you want the system to follow individual user-defined steps when it processes an approval. Dynamic: A dynamic path definition contains only one step. When begun, the single step definition can yield any number of instances in sequence. When using a 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 of these instances are queued in sequence.
Skip Prior Steps for Requester	Select to indicate that if one of the approvers in this path is also the requester,the system should skip all steps in the path prior to that approver's step.

Escalation Options

Use the fields in this group box to tell the system who to notify or reassign approvals to when an approver takes too long to approve or deny a pending request.

Options	Notify: Sends an email, or whatever notification is defined in the transaction registry, to the individual or individuals identified in the User List field. Reassign: Reassigns the approval step to an operator ID or a user list.
Hours	Enter the number of hours that a transaction can remain at the same workflow step before being escalated. This field is combined with the number of days in the Days After Beg field to determine the total time an approver has to take action on an approval request.
Days After Beg (days after beginning)	Enter the number of days a transaction can remain at the same workflow step before being escalated. This is the length of time that an approver has to approve, deny, or push back a transaction.
Advance	Select to skip the current approver.
Reassign To	If you select Reassign as the option, you can enter a user name or a specific user list containing the individual(s) to whom the approval request should be reassigned. Note. A user list reassigns the approval step to the first user in the list who does not match the current user.
User List	Select the list of users the workflow notification or task should be routed to. You define user lists on the User List Definition page. See Setting Up User Lists.

Defining Step Details

Access the Approval Step Definition - Step page.

Step Number

Enter the number of the step.

This number determine the routing sequence. Each step typically represents one approver. However, it is possible to route an enrollment or registration request to multiple approvers or reviewers in the same step.

Criteria

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

Approver User List

Select the user list that contains the authorized approvers for this step. You define user lists on the User List Definition page.

See Setting Up User Lists.

Approver Role Name

In addition to using user lists to control approval authorization, you can add roles to limit approval rights.

Select the role that members of the user list must be in before they can be granted approval authority. Approvers must be in this role when they act on an enrollment or registration request. If their role assignment changes, the system prevents them from acting on the request.

All Approvers Required

Select to indicate that all approvers must approve the learning request at this step.

Some Approvers Required

Select to indicate that not all approvers have to authorize a learning request. If you select this option, you can define the number of required approvals in the Number of Approvers Needed field.

Number of Approvers Needed

Enter the minimum number of approvers required to authorize a training request at this step. When this number can't be met, the system notifies the user identified in the Admin Role field on the Approval Process Definition page.

Self Approval

If the originator of a learning request is also an approver in the approval process, select Self Approval to enable automatic self-approval of the request. In this situation the requester's approval is assumed and his/her approval step is skipped.

If desired, you can establish criteria to limit the requester's self-approval authority by clicking the Self-Approval Criteria link. For example, you can define a monetary limit for the requester so that if a transaction is over that amount, the request is not automatically approved. However, if the self-approval criteria are met, the requestor's approval is assumed and his/her approval step is omitted. If the criteria are 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.

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

If self-approval is not enabled, the system does not consider the requester an approver for that transaction.

Self-Approval Criteria

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

Reviewer User List

Select a user list containing the individuals you want to review this step. You define user lists on the User List Definition page.

See Setting Up User Lists.

Setting Up the Transaction Registry and Additional Notifications

To set up the transaction registry and create additional notifications, use the Transaction Registry (SAC_AW_TXN) component.

This section provides and overview of the transaction registry and additional notifications, and discusses how to:

Register approval transactions.
Define additional notification options.

Understanding the Transaction Registry

The approval transaction registry is the interface you use to register a transaction with the approval workflow engine. Transactions that require approvals are candidates for being linked to the approval workflow engine. You use the Approval Transaction Registry page to connect the components, event handler, records, and classes that you create to the approval process for an application transaction, such as an enrollment request. You register the main records and components that make up the transaction, and then select the approval transaction on which to base the approval process definition.

Note. Enterprise Learning Management delivered approvals are already recorded in the Approval Transaction Registry. No additional configuration is necessary.

Understanding Additional Notifications

Enterprise Learning Management enables you to define additional notifications that are not part of the default notifications sent to users during the approval process. For example, the system always notifies approvers when there is a pending worklist item, and when an error occurs in the approval process, the system always notifies both the requester and the system administrator. However, you may want to add additional notifications when there is an error in the approval process, an approval is escalated because an approver fails to act on a worklist item, or in response to other events.

To set up additional notifications, access the Notification page and specify the following elements:

The event that triggers the notification.
The recipients of the notification.
The worklist or other pages in Enterprise Learning Management that you want notification recipients to link to for additional information or to perform an action.

Note. You can embed links to database pages in a worklist or email notification to take notification recipients to a specific page in the database.
The notification channel (email or worklist).
The template containing the message you want to include in an email notification.

Prerequisites for Registering a Transaction

Before defining the transaction registry:

Create a Transaction Handler Application Class which extends an approved event handler class delivered by approval workflow.
Create notification templates for the events to include approval and denial for headers and for 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.

Note. See your PeopleTools documentation for more information about defining application classes, notification templates, and views.

See Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide

Pages Used to Define the Approval Transaction Registry

Page Name	Object Name	Navigation	Usage
Approval Transaction Registry	SAC_AW_TXN	Set Up ELM, Approvals, Transaction Registry, Approval Transaction Registry	Register a transaction with the approval workflow engine.
Notification	SAC_AW_TXN_NOTIFY	Set Up ELM, Approvals, Transaction Registry, Notification	Define who should be notified when a transaction-related event occurs, such as when a transaction ends up in error, is escalated to someone outside the standard approval queue, is denied, or is pushed back.

Registering Approval Transactions

Access the Approval Transaction Registry page.

Approval Process ID

The system uses the approval process ID displayed here to manage the approval workflow process for a transaction. You can also enter a description of the approval process.

Object Owner ID

Select the PeopleSoft application to which this object belongs.

Cross Reference Table

Select the table used to manage application-specific transaction records and associate them with the approval process run time instances. Each time a learning request launches an approval process, the system tracks the process by the header level records of the application. The cross-reference table makes it possible for the system to relate the approval process instance to the transaction instance.

For a given application transaction record, this cross-reference information tells 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.

Worklist Approval Component

The fields in this group box identify the default component that users access to view or select 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 based.

Approval Event Handler Class

Use this group box 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 Enterprise Learning Management, 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 Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide

AdHoc Approver Logic Class

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.

Thread Desc(thread description package)

Select a thread description package.

The package defines how the transaction details are displayed in the system in the status monitor. Behind the scenes, approvals are defined with a sequence number. This allows for a user-friendly display.

Note. Access the approvals status monitor for Enterprise Learning Management administrators by going to Enterprise Learning, Learner Tasks, Monitor Approvals.

Adhoc Class / Class Path

Select the ad hoc application class and class path. Adding approvers and reviewers is handled by the class you define here.

Note. If a transaction has restrictions on adding approvers or reviewers that cannot be managed by the default class, an application developer needs to create a new adhoc class.

Transaction Approval Levels

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

Note. Enterprise Learning Management supports only header level approvals.

Header or Line Level	Define what levels 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.
Field Label ID	Select the field label ID associated with the Record (Table) Name field.

Defining Additional Notification Options for Approval Transactions

Access the Notification page.

Header or Line Level

Select the level at which you want a notification sent for an event, either Header or Line.

Note. Enterprise Learning Management supports only header level notification.

Event

Select the event that triggers the notification. By default, approvers are always notified of worklist items for which they are responsible. And when an error occurs, the system notifies the requester and the system administrator.

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

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 approvals only.

Menu Name / Approval Component

Select the menu and component that you want the the recipient of an email notification to access. A link to this component appears in the email, and the recipient can then act on the information contained there. If you do not enter any values, the recipient is sent to the menu and component specified in the Worklist Approval Component group box on the Approval Transaction Registry page.

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.

Approval Participant

Define the user to notify when this event takes place.

Admin

Approver

Dynamic

Requester

Reviewers

User List

Notification Channel

Defines how the participant will be notified.

Both: The participant receives worklist items and email.

Email: The participant receives email.

None: The participant receives no notification.

User: The system uses the notification channel(s) selected for the individual user on the User Profiles (USERMAINT) component.

Worklist: The participant receives worklist items.

User List

Select a user list to define the participant(s) to notify.

Template Name

Select the generic template you want to use for the email content of this notification.

Setting Up Approver Authorization

To set up approver authorizations, use the Approver Authorization (SAC_AW_AUTH) component.

This section provides an overview of approver authorizations, and describes how to set up authorizations.

Understanding Approver Authorizations

You can identify the approver authorization by role or user in conjunction with a dynamic step. To accomplish this, the approval workflow engine selects the appropriate supervisory approvers 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 all SetIDs or for a specific SetID.

For each authorization the system checks the specific user ID to see if that individual could be a potential authorizer for the transaction. If the user is found, it checks the authorization criteria. If criteria are met, the user has the required authorization.

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

To determine the approval hierarchy, the system first looks for authorization by SetID. If no authorization is found, the system then seeks authorization for rows with a blank for the SetID. If no authorization is found, the system process is deemed “Not Authorized”.

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

Note. Enterprise Learning Management supports only header-level authorization.

When workflow is initiated, the system compares the approval authorization data to the user list to verify the approval. To verify the approval, the system:

Checks the user list, and assign the first approver to the first user returned from the user list.
Looks to the roles established for the user ID.
Identifies the approval limits set for that individual user ID.
Continues to look for additional approvers until all conditions are met.
Routes the approval to the administrator if the approver criteria is never met.

Pages Used to Set Up Approver Authorizations

Page Name	Object Name	Navigation	Usage
Approval Authorization	SAC_AW_AUTH	Set Up ELM, Approvals, Approver Authorization, Approval Authorization	Set up approver authorization by role or user.
Criteria Definition	SAC_CRITERIA	Click the Criteria link on the Approval Authorization page. Click the Self-Approval link on the Approval Authorization page.	Set up approval criteria for each user or user role that you select. Enable self-approval and define self-approval criteria.

Setting Up Approver Authorizations

Access the Approval Authorization page.

SetID

Enter a SetID

If you don’t specify a SetID, the authorization is generic across all SetIDs. To create an approval authorization for multiple SetIDs, you must add a line for each SetID.

Role Name

Select a role that you want authorized as an approver when this approval process is used. You can select a role name or a user ID for each row, but not both.

User ID

Select the user you want to authorize as an approver when this approval process is used.

Criteria

Select to access the Criteria Definition page where you can set up approval criteria for each user or user role that you select.

Self Approval

Select to access the Criteria Definition page, where you can define the conditions under which the system allows self-approval of learning requests.

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

Defining Role, User, and Self-Approval Criteria

Access the Criteria Definition page.

Use this page to:

Set up approval criteria for roles or users.
Enable automatic self-approval and define the conditions under which users or user roles can approve their own learning requests.

If self-approval is enabled, and the requestor of a transaction is also an approver, the requester's approval is granted automatically and his/her approval step is omitted. If desired, you can establish criteria to limit the requester's self-approval authority. For example, you can define a monetary limit for the requester so that if a transaction is over that amount, the request is not automatically approved. However, if self-approval criteria are met, the requestor's approval is assumed and his/her approval step is omitted.

If self-approval is not enabled, the system does not consider the requester an approver for that transaction.

SetID	Select a SetID. Learning Environments uses SetIDs to limit access to approval processes.
Admin Role (administrative role)	Select the user list role used 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.
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 in the approval process.
User Auto Approval	A user may participate more than once in the same approval process. Select User Auto Approval to enable the system to remember a user's initial approval actions in an approval process. The next time this user is asked to take an action in the process, the system automatically reproduces the user's earlier actions. The system continues to repeat these actions until you clear the User Auto Approval check box.

Step Number	Enter the number of the step. This number determine the routing sequence. Each step typically represents one approver. However, it is possible to route an enrollment or registration request to multiple approvers or reviewers in the same step.
Criteria	Click to access the Criteria Definition page where you can define field criteria along with monetary and application class criteria.
Approver User List	Select the user list that contains the authorized approvers for this step. You define user lists on the User List Definition page. See Setting Up User Lists.
Approver Role Name	In addition to using user lists to control approval authorization, you can add roles to limit approval rights. Select the role that members of the user list must be in before they can be granted approval authority. Approvers must be in this role when they act on an enrollment or registration request. If their role assignment changes, the system prevents them from acting on the request.
All Approvers Required	Select to indicate that all approvers must approve the learning request at this step.
Some Approvers Required	Select to indicate that not all approvers have to authorize a learning request. If you select this option, you can define the number of required approvals in the Number of Approvers Needed field.
Number of Approvers Needed	Enter the minimum number of approvers required to authorize a training request at this step. When this number can't be met, the system notifies the user identified in the Admin Role field on the Approval Process Definition page.
Self Approval	If the originator of a learning request is also an approver in the approval process, select Self Approval to enable automatic self-approval of the request. In this situation the requester's approval is assumed and his/her approval step is skipped. If desired, you can establish criteria to limit the requester's self-approval authority by clicking the Self-Approval Criteria link. For example, you can define a monetary limit for the requester so that if a transaction is over that amount, the request is not automatically approved. However, if the self-approval criteria are met, the requestor's approval is assumed and his/her approval step is omitted. If the criteria are 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. Note. If the criteria are not met, and there is no later step, the system inserts an additional step. This step is then routed to the administrator. If self-approval is not enabled, the system does not consider the requester an approver for that transaction.
Self-Approval Criteria	Click to access the Criteria Definition page, where you can set up self-approval criteria for a user, including field criteria and monetary and application class criteria.
Reviewer User List	Select a user list containing the individuals you want to review this step. You define user lists on the User List Definition page. See Setting Up User Lists.

Header or Line Level	Select the level at which you want a notification sent for an event, either Header or Line. Note. Enterprise Learning Management supports only header level notification.
Event	Select the event that triggers the notification. By default, approvers are always notified of worklist items for which they are responsible. And when an error occurs, the system notifies the requester and the system administrator. 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 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 approvals only.
Menu Name / Approval Component	Select the menu and component that you want the the recipient of an email notification to access. A link to this component appears in the email, and the recipient can then act on the information contained there. If you do not enter any values, the recipient is sent to the menu and component specified in the Worklist Approval Component group box on the Approval Transaction Registry page.
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.
Approval Participant	Define the user to notify when this event takes place. Admin Approver Dynamic Requester Reviewers User List
Notification Channel	Defines how the participant will be notified. Both: The participant receives worklist items and email. Email: The participant receives email. None: The participant receives no notification. User: The system uses the notification channel(s) selected for the individual user on the User Profiles (USERMAINT) component. Worklist: The participant receives worklist items.
User List	Select a user list to define the participant(s) to notify.
Template Name	Select the generic template you want to use for the email content of this notification.

SetID	Enter a SetID If you don’t specify a SetID, the authorization is generic across all SetIDs. To create an approval authorization for multiple SetIDs, you must add a line for each SetID.
Role Name	Select a role that you want authorized as an approver when this approval process is used. You can select a role name or a user ID for each row, but not both.
User ID	Select the user you want to authorize as an approver when this approval process is used.
Criteria	Select to access the Criteria Definition page where you can set up approval criteria for each user or user role that you select.
Self Approval	Select to access the Criteria Definition page, where you can define the conditions under which the system allows self-approval of learning requests.