PeopleSoft has moved from the traditional workflow to the Approval Workflow Engine. Approval Workflow Engine (AWE) also known as Approval Framework is the framework providing capabilities to create, run and manage the approval processes within PeopleSoft. When the user submits a transaction, the application hands the transaction over to Approval Workflow Engine, which will determine the appropriate approval process definition and then launch the required routing based on the steps configured.
 
There are two types of approval process :
  1.  Header Level – Header level approval is the commonly used approval process in AWE where only the top level header record is used and transaction lines are grouped together and processed as one unit.
  2.   Line Level – In line level approval, action can be  taken on different line items  without waiting for the approval of other line items. In this case, the application can act on the individual lines as they get approved. Each item can be routed to different approvers. For example, if a purchase order contains multiple line items, each line item is treated as a different transaction. So, if you order laptops,printers and desktops, you might obtain approval for laptops only, and not for printers and desktops. The denial of printers and desktops will not have any impact for the approval process of laptops. If treated as a header approval, the entire PO would have been denied. This is the advantage of line level processing.

Business benefits of Line Level Approval:

 
  •  In line level approval, multiple approvers can be included for individual steps
  •  Each item can be routed to different approvers, based on certain criteria.
  •   Denial /Approval of one line item does not  affect the other.
There are many websites for detailed study on Header level approval. Here, let us have a glance on Line Level Approval with an example.
 

Line level approval:

Most of the steps in line level are same as Header level approval. Let us see a sample workflow process using line level approval.

Sample Test Case:

An employee tries to submit different items (Laptop, Desktop and Printer) based on the asset id. Each item is routed to different approvers and the approver can approve only the specific items routed to him/her.
 A component has to be created for the employee to submit the asset items and for the managers to approve/deny them. Let’s see the process step by step.
 
Development Steps:
 
Step 1: Create a top-level header record ASSET_ID as key-field. Also, create a line record with ASSET_ID and KOV_ITEM_NAME as keys. For header level approval, only the header record is enough.
KOV_TEST_HEADER:
 
 
KOV_TEST_LINE-
 
Step 2: Create a cross reference record with the key-fields used in header and line record as non-keys here to link the workflow process to PIA. Include the EOAW_XREF_SBRdelivered sub-record in this record for getting the thread values.
 
Step 3: Design a standard page with the header record at level 0 and line record at level 1 as shown below. Include the delivered sub-page EOAW_MON_SBP to this page for displaying  the Approval status monitor.
 
Step 4: Create a new component with the header record as search record. Place the page in this component and register the component to a menu.
 
Step 5: Give the appropriate permission lists and security access to the component.
 
Step 6: Coming to the PIA configuration, navigate to Set Up HRMS -> Common Definitions -> Approvals -> Transaction Registry. Add a new Process ID and specify the cross reference, header and line level record names as shown below. Create a new application package and a class and include it here. The coding for app package is mentioned later.
 
Step 7:  Create three generic templates for submission, approval and denial by navigating to Set Up HRMS -> Common Definitions -> Approvals -> Generic Templates. The emails triggered to the requester and approver will be in the format of this template created. Create a SQL to fetch the bind values mentioned in the template. Like the approval template shown below, similarly create a template for submission and denial mails. This step is needed only if business requires notifications to be sent, else creation of generic templates is optional.
 
Step 8: Navigate to Set Up HRMS -> Common Definitions -> Approvals -> Transaction Configuration. Here, add the following four events:
a)      On Process Launch (Header level)
b)      On Final Approval (Line Level)
c)       On Final Denial (Line Level)
d)      Route For Approval (Line Level)
 
 
 
If generic templates had been created earlier step , then mention those names here to each event respectively, but this is not mandatory.  For header level approval, all the events specified, including “On Final Approvalâ€� and “On Final Denialâ€� must be given as Header level only.
 
Step 9: Navigate to Set Up HRMS -> Common Definitions -> Approvals -> Approval Process Setup. Add a new Definition ID for the process id created.
 
a)      The checkbox “Take Action on Line Completionâ€� gets automatically checked for line level approval.
b)      Approver Userlist can be created by mapping it to a specified role or Application Package, SQL or Query. The  approvalof  submitted transactions are  based on certain criteria.
c)      Stage is a collection of paths and can be at header level or line level. As level here, specify line level is being used here , create 3 paths.
d)      A path is a collection of steps and since we have 3 items here.Once a transaction is being submitted,it will route to three different approvers as shown above.
Printer – Department Head
Laptop – Manager
Desktop – Admin
e)      Click on the Definition Criteria and Alert Criteria links and give it as always true. In all the three path level criteria, mention the criteria as “User Enteredâ€� and enter the record field value which must be considered for approving.
 
 

In the above screenshot, the value is entered as “L� which stands for Laptop. So, the Userlist mapped to this value can approve only Laptop transactions. Similarly, for Desktop and Printer, criteria is added and values are given as “D� and “P� respectively.

 
Step 10: In the backend, the coding in work record buttons FieldChange and the Component PostBuild are same as the Header level coding. There are few changes in SavePostChange coding for passing the line record which is highlighted below. The coding in Application Package includes two more events “OnLineApprove� and “OnLineDeny� other than the events used in Header level approval.
   Component SavePostChange:
/***
 * AWE SavePostChange Code
 * This Save Post Change Code Will Handled When Submit, Approve & Deny Action Performed
 **/
/** Import Approval Framework Base Classes */
import EOAW_CORE:LaunchManager;
import EOAW_CORE:ApprovalManager;
/** Declare functions*/
Declare Function createStatusMonitor PeopleCode EOAW_MON_WRK.EOAW_FC_HANDLER FieldFormula;
Component EOAW_CORE:LaunchManager &c_aweLaunchManager;
Component EOAW_CORE:ApprovalManager &c_aweApprovalManager;
Component string &sbmt_action;
Component string &c_AWEProcessDefnID;
Component Record &headerRec; /** We have set it Component Level, So Get Acess to Others Component **/
Component Rowset &line_rws;
Local Record &line;
Local number &i;
&line_rws = GetLevel0()(1).GetRowset(Scroll.KOV_TEST_LINE);
Local boolean &IsActionTaken = True;
Local string &sActionMsgString = “”;
Evaluate &sbmt_action
When “S”
   /* Call DoSubmit, passing in current header info.  ;*/
   /** It is always safe to call this method (as long as the header record being passed in is valid!), */
   &c_aweLaunchManager.DoSubmit();
   If (&c_aweLaunchManager.hasAppInst) Then
      /** Initialize Approval