PEOPLESOFT

WORKFLOWS- DESIGN &

ENHANCEMENTS
By
Avinav Goel
Tata Consultancy Services

w.r.t.
Peopletools ver. 8.46
PeopleSoft Enterprise Apps. ver. 8.8
 OBJECTIVE
• What is a WORKFLOW
Many of the day-to-day processes in business are part of larger tasks that involve several steps
and several people working together. For example, when you enter an invoice, you are initiating
an approval and payment process: someone else reviews and approves it, and a third person
submits payment to the vendor. The term workflow refers to this larger process. With respect to
ERP (Enterprise Resource Planning), a workflow involves a set of approvers (generally in a
hierarchical fashion) having different options (approve/deny/send back/sanction) towards a
financial transaction (purchase order/budget sheet) or an HRMS feature (leave/loan).

• TARGET AUDIENCE
This white paper intends to guide a PeopleSoft Application Developer quickly and simply on how
to design and prepare workflows. Further, some enhancements and alternatives are also
mentioned to better utilize the power of workflows. The paper would be found useful by a
PeopleSoft Functional too to gain insights into the general logic and mapping of workflows.
 Chapter 1- Design
METHOD 1- triggerbusinessevent () based

STEPS TO CREATE A SIMPLE WORKFLOW

1. Create an Activity in Application Designer (File > New > Activity).
2. Insert a Step, Event and Worklist in the activity and connect these through links as shown
in the fig. below,
Link to connect the Step
Event and Worklist

Worklist
Step Event

3. Create a Business Process (File > New > Business Process) and insert the created activity into
it.
? Business Process
A business process is a graphical representation of the relationships between related activities.
Arrows show the relationships between the activities, indicating the proper chronological
sequence.
 Multiple Activities can be
inserted in a single
Business Process

4. Activity Features,
4. i. STEP

Set the name of the

Step and its
description
 Menu name of the target
component which the approver will
open through worklist

Bar Name of the target

component

Item Name of the target

component

Set the name of the target page

which the approver will open
through worklist

Set the mode in which approver will

open the request

4. ii. EVENT
Define the event and go to ‘Edit Business Rules’ and write the following workflow code there,
&SUCCESS = TriggerBusinessEvent (BusProcess.MCA_HLO_BP, BusActivity.MCA_HLO_FIN_ACT2,
BusEvent."Medical Advance Final Status");
where
1. BusProcess is the name of the Business Process created
2. BusActivity is the name of the Activity
3. BusEvent is the name of the Event created in the activity

Triggerbusinessevent() function should only be used in Workflow PeopleCode. Returns a Boolean

value: True if successful, false otherwise. The return value is not optional.
 Set the record name from
which workflow event is to
be triggered

4. iii. WORKLIST
This is the most important setting that determines the nature of your workflow,

Set the name of the Worklist and

its description

• Setting the Attributes in the Worklist

1. Set the Worklist record
2. Set the name of the Business Process of this activity
3. Set the name of the Activity
 Options to delete worklist -
1. Set User Specified when
the worklist is to be
deleted manually
2. Set Saved when the
worklist is to be deleted
while saving the worklist
page
3. Set Selected when the
worklist is to be deleted as
soon as it is selected
4. Set Programmatic when
the worklist is to be
deleted through coding

Set Reassignable when the

approver has the authority to
reassign to some other
approver

Set the Timeout Processing Active when the worklist is

to be deleted after a specified time

? Worklist Record
Worklist record determines which fields of information the system stores for each work item and
in what order the work items appear. When a business event routes a work item to a worklist, it
adds a row to the table. When a user finishes with a work item, the system marks the row as
worked.

Worklist Record Definitions

When you create a worklist record definition, you define what a work item in a worklist looks
like. The system uses the worklist record definition to:
• Link each work item with the underlying workflow tracking information, which is stored
in a workflow system record (PSWORKLIST).
• Display relevant information about each work item on the Worklist page, so that users can
select the item on which they want to work.
• Determine the order of work items in the worklist.
• Retrieve the record that is associated with the work item, so that the user can work on it.
System Fields
The first fields in a worklist record definition must always be the following system fields.

System Field Description

BUSPROCNAME The business process that includes the work item.

ACTIVITYNAME The activity that triggers the worklist routing.

EVENTNAME The business event that triggers the worklist routing.

WORKLISTNAME The worklist in which the work item is waiting.

INSTANCEID The system-assigned ID for the work item.

TRANSACTIONID The system-assigned transaction ID for the work item. When an event
triggers multiple routings, each work item has the same transaction ID, but
a different instance ID.

The system uses these fields to link the items in the worklist with their tracking information,
which is stored in the PeopleSoft-defined table PSWORKLIST. They must be defined as
ascending key fields in the worklist record definition.
Virtual Approver, a specialized type of workflow used for approval processes, requires one
additional system field. If you’re using Virtual Approver, you must also add the
APPR_INSTANCE field as a non-key field in the worklist record definition. This field stores the
ID assigned to the work item for Virtual Approver processing.

Application Fields
The next set of fields in a worklist record definition are those specific to the application that
creates the worklist. The system uses these fields to retrieve the associated record from the
database when the user selects a worklist entry and moves to the page where the work is done.
Note the following:
• Because the system uses the values from these fields to search for the associated database
record, you must include all of the key fields for the search record.
• The order of the fields is important. The system sorts the work items in a worklist based
on the field immediately following the TRANSACTIONID field, then the next field, and
so on. It sorts based on all key fields in the record definition.
• All of the application fields appear in the user’s worklist, unless you suppress them by
including the special field WORKLIST_DESCR.

Worklist Display Fields

The last two fields in a worklist record definition are for descriptive information that appears in
the worklist.

Worklist Display Description

Field

WORLKIST_URL The text that links to the page where the user can work on the item.
Appropriate values might include the key data for the record in which the
 Worklist Display Description
Field

item will be worked. For example, for a work item directing a manager to
approve an expense report, the text might be the name of the employee
who submitted the report.

WORKLIST_DESCR A text comment that appears in the user’s worklist. The presence of this
field automatically suppresses the display of any application fields,
although the key fields are still used to bypass the search page of the
target page.

On the Worklist Details page, these values appear as the Link and Comment fields. The link also
appears on the main Worklist page.
Creating Worklist Record Definitions
1. Add the required system fields to the record definition.
2. Add the key fields from the search record for the page that group users use to process the
worklist entries.
Make them key fields so that they’re used to sort the work items. The worklist record must
include the search record key fields so the system can locate the record on which the user
must work.
3. Save the record definition using a name that ends with _WL.
4. Create a database table using the record definition that you saved in step 3.

Mapping the fields of the Worklist Record,

OPRID should be mapped with Map the Key values of the

the userid of the approver. worklist record to the Key
OPRID can be mapped directly values of the approver’s
or through a role query search record
Mapping the Key fields,

Mapping the OPRID (Operator Id or Id of person logging in),

Query through which OPRID can

be mapped. This query can be
created through Application
designer or through front end.
METHOD 2- APPROVAL RULE SET WORKFLOWS (ARS)

1. Create a Route Control Type such as Business Unit or Administrative Area.

? Route control types
These identify the situational factors on which you want to base routing decisions. E.g., to route
purchase requisitions to different buyers based on which vendor can supply the requested item,
you create a Vendor route control type. Later, you specify with whom each buyer works.
Here you need to specify the edit table. The values of the key field of this record would be
used for Route Control Profile. E.g. BUS_UNIT_TBL_FS table has been used for the
Business Unit Route Control Type and the values (all business units) would be used for Route
Control Profile. Once you give the Required Edit Table Name, save the Page.

Adding Route Control Types

i. Go to PeopleTools> Workflow> Routings & Roles> Route Control Type (eg. Business
unit)
ii. In the Edit Table drop-down list, select the prompt table against which you want to
validate values.
iii. Save this page and repeat the process for each route control type.

2. Create a route control profile as follows,

i. Go to PeopleTools> Workflow> Routings & Roles> Route Control Profiles
ii. Select a route control type from the Route Control Type drop-down list.
The route control type specifies the prompt tables to which this profile applies.
iii. Specify the range of values from the type’s edit table that users with this profile can
process.
To provide access to a continuous range of values, select the lowest value in the From
Value field and the highest value in the To Value field. To provide access to a single value,
select the same value in both fields. To provide access to two values, add a new row to the
Authorized Values field.
(Optional) Assign values for another route control type.
You can assign values for more than one route control type to the same route control
profile. With your cursor in the Route Control Type field, click the Add button. Select a
new route control type. Assign its authorized values.
Make the Route Control Profile and Assign the From and To values to it, e.g. BUS(RC101) has
Route Control Type Business Unit and the Route Control Profile values are From : RC101 and
To : RC101. If you want to make a profile having more than one values of that Route Control
Type then add multiple rows of ‘From’ and ‘To’ Prompts. Alternatively, if a Route Control
Profile shall contain many values, list the first and the last value as stored in the edit table
(sequentially).
 Finally, Attach Route Control Profile to the Userid used in the Approval Process. Go to 3rd tab
of the Userid Component and there attach the Route Control Profile corresponding to the
Required Role (through Route Control Hyperlink).

Navigation: PeopleTools > Security > User Profiles > User Profiles
Attaching route control Profile(s) to a Userid means that this User is allowed to approve the
transactions related to this route control profile(s) only. Basically, a security feature in
workflows.

Application Designer Procedure:

? Aapproval Rule Set

An approval rule set is a workflow map representing the criteria for determining which approvals are
required for a transaction. The components of the map are individual approval steps: one for each level of
approval.

To create an approval rule set,

1. File>New>Approval Rule Set
2. Save the rule set and assign an effective date.
Unless you specifically want to make the approval rule set effective at a particular time,
PeopleSoft recommends a standard effective date, such as 01/01/1900.
3. Open the Approval Rule Properties dialog box by selecting File, Properties.
The Approval Rule Properties dialog box appears, displaying the General tab.
4. Enter descriptive information about the approval rule set.
Use the Icon Descr (icon description) field to specify a description that appears next to the
rule set’s name in dialog boxes that list approval rule sets.
5. Specify whether users can approve their own transactions.
Select Allow Self Approval if users are permitted to approve transactions that they’ve
entered. Selecting this option does not mean that transactions are automatically approved;
self-approval is still subject to the person’s approval limits.
6. Select the Use tab. Enter the name of the business process that is associated with this rule
set.
When you add PeopleCode to call Virtual Approver from the transaction page, this
business process is one of the input parameters.
7. Specify the event to trigger when all required approvals have occurred.
In the On Authorized group box, enter an activity name (associated with the business
process that you’ve specified) and event nameto specify which event should be triggered
when the transaction is fully approved. Virtual Approver triggers this event when final
approval occurs. For example, after a purchase requisition is approved, it is logical to
trigger an event that notifies a buyer that the approved requisition is ready to be fulfilled.
8. Specify currency units for the approval rules.
9. Specify the currency unit for the transaction.
Rule steps are the individual approval steps. Approval rule sets incorporate one rule step for each
level of approval that might be required.
When the person who submits something for approval has no self-approval authority, you do not
need to include a step for that person. However, you may include a step for that user so that your
graphical map more clearly documents the entire process. As long as that user has no
authorization authority, Virtual Approver bypasses that user anyway.
If users who submit items for approval have some level of authorization, for example, users can
self-approve amounts up to USD 100, and then the first rule step must represent that approval
level.

select all of the roles that Specify whether the

are qualified to process system can bypass
The role that you select is the the transaction at this step. this approval step if
role of the user who approves additional approval is
items at this step and path. required.

Workflow If a transaction needs further approval, this forwards it on to the next step without
Only informing the user.
Message The user sees a message indicating that the transaction needs further approval, but
Only the transaction doesn’t enter the workflow.
Both Displays a message asking the user whether to add the transaction to the workflow.
If you select Message Only or Both, the message comes from the PeopleSoft
 Message Catalog. Use the Message Catalog setting to specify the set and number of
the message that the user sees.

1. In the Appr Step (approval step) and Appr Path boxes, specify which step you’re defining.
Approval processes can have multiple steps (in sequence) and multiple paths (in parallel).
The purchase request example following this procedure has several steps, but only one
path. An example of a process with multiple paths is one in which requests must be
approved by the department manager and an office manager before going to a vice
president. Here is sequence of steps and paths in this case:

Step Path Route to Role

1 A MANAGER (DEPTARTMENT)

1 B MANAGER (OFFICE)

2 A VICE PRESIDENT

In this example, the system sends two worklist entries when a new request comes in: one
to the department manager and one to the office manager. When both of the managers
approve the request, the system forwards it to a vice president.
RULES tab
Specify which transactions the specified role users have the authority to approve.
You can specify which transactions a user can authorize in the following three ways:
• If approval requirements are based on a monetary amount, enter the criteria in the
Amount Rule group box.
• The user can authorize transactions whose monetary amount is between the values
in the Min and Max fields. The associated record and field specify the record and
field containing the amount in the original transaction.
• If approval criteria are based on a (non-monetary) quantity, enter the criteria in the
Quantity Rule group box. The user can authorize transactions in which the (non-
monetary) quantity is between the values in the Min and Max fields. The
associated record and field specify the record and field containing the quantity in
the original transaction.
• If the approval criteria are based on the approver’s user data, enter the criteria in
the Row Level Rule group box.
• There are two methods of obtaining row level criteria: using a route control or a
SQL object. If you select Route Control, the range of transactions that the user can
authorize is determined by the user’s route control profile. The system compares
the value from the specified record and field to the user’s route control profile. If
the value is in the range to which the route control profile gives the user access, the
user can approve the transaction.
EVENT tab
Select the Events tab to specify which business events are triggered, depending on the action of
the approver at this step.
Select the business event to Specify which events to
trigger when this approver trigger if the user denies or
approves the transaction. recycles the transaction.
NOTE: Generally in the worklist ‘field mapping’ of the above listed activity, the OPRID field is
linked through RoleName>One Route Control Query. Here in ‘specify query bind variables’, the
mapping of the listed 4 fields is done as follows: -
RolenameÆ appr_fields_wrk.rolename
Rte_cntl_type_1Æ appr_fields_wrk.Rte_cntl_type1
Rte_from_value_1Æ appr_fields_wrk.fld1
Rte_to_value_1Æ appr_fields_wrk.fld1

Alternately, we may map it to a constant if we want the workflow to be triggered to one particular
approver always (through triggerbusinessevent ()).
Adding Workflow Work Pages:
Every component that uses Virtual Approver PeopleCode must include the pages
WF_FUNCTIONS_01 and APPR_WRK_01. These special work pages load several important
Workflow PeopleCode functions into memory. For example, if you’re using route controls,
WF_FUNCTIONS_01 enables the system to determine which route control types are relevant for
the event that you’re triggering.
NOTE: while including the 2 extra pages in the component, these should be made hidden.
Adding Virtual Approver PeopleCode
After you add the Virtual Approver work pages to the component with the page where the
triggering event occurs, you must add both SaveEdit PeopleCode and Workflow PeopleCode to
the record definition that is associated with that page.

NOTE: include the three fields APPR_ACTION, APPR_INSTANCE & APPROVAL_STATUS

in your main record and APPR_ACTION & APPROVAL_STATUS on your page

SaveEdit PeopleCode
This is the general structure of the SaveEdit PeopleCode program:
1. Declare the external workflow functions Get_RoleUser and Virtual_Approver.
2. Set values in the APPR_FIELDS_WRK work record to give the Virtual_Approver
function the data it needs to check the approval rules.
Set these values:
• The name of the role user attempting to approve the transaction.
• The business process and approval rule set you want Virtual_Approver to use.
• The approval action that the current user gave to the current work item. The valid
status values are A (Approve), D (Deny), or R (Recycle).
3. Use the Virtual_Approver function.
4. Set the approval status record field to the value that Virtual_Approver returns: A
(Approved), D (Denied), and P (Pending).
Enter the following code exactly as it’s shown, replacing the values in angled brackets
with the values that are appropriate for your application.
NOTE: the following code should be written on an event of a non-key field of the record
like APPR_FIELDS_WRK.APPR_ACTION
/* Declare the Virtual Approver workflow functions */
declare function Get_RoleUser PeopleCode APPR_VA0_WRK.ROLEUSER FieldChange;
declare function Virtual_Approver PeopleCode APPR_VA0_WRK.FUNCLIB_01 FieldFormula;
/* Get the role user name for the current user */
&USERID = %UserId;
Get_RoleUser(&USERID, &EMAILID, &FORMID, &EMPLID, &ROLEUSER);

/* Set values in the work record for Virtual_Approver */

APPR_FIELDS_WRK.ROLEUSER = &ROLEUSER;
APPR_FIELDS_WRK.BUSPROCNAME = BUSPROCESS.<BusProcessName>;
APPR_FIELDS_WRK.APPR_RULE_SET = <approval_rule_set>;
APPR_FIELDS_WRK.APPR_ACTION = <approval_action>;
APPR_FIELDS_WRK.APP_ROW_NUMBER = <current_row_number>; /*OPTIONAL*/
APPR_FIELDS_WRK.APPR_INSTANCE = <RECORD>.APPR_INSTANCE;
 /* Call the Virtual Approver */
Virtual_Approver();
/* Set the application record’s approval status field to the value */ /* Virtual_Approver returns */
<status_record_field> = APPR_FIELDS_WRK.APPR_STATUS;

The variables in this code are:

BusProcessName The name of the business process whose approval rules to use.
Approval_rule_set The name of the approval rule set that you want Virtual_Approver to use
to determine whether an item needs further approval.
Approval_action The approval action to provide Virtual_Approver as input. Usually,
approval_action is the name of the record field in which the user sets the
approval status. It can also be one of the string constants: P, D, or R.
Note. If the user specifies the approval action at level 0 on the page—that
is, if the user specifies a single approval action for the entire page—it’s
preferable to include the field APPR_FIELDS_WRK.APPR_ACTION on
the page and let the user set it directly. However, this direct approach
doesn’t work if the user must specify approval actions for each row in a
scroll. You must have the user set the action in another field, then transfer
the value to the APPR_ACTION field before the Virtual_Approver call.
Current_row_number The current row number in the scroll. Setting this field is not necessary at
level 0.
Status_record_field The record field that holds the approval status of the transaction, such as
Purchase Request Approval Status.

Workflow PeopleCode
declare function Virtual_Router PeopleCode APPR_VA0_WRK.FUNCLIB_02 FieldFormula;
APPR_FIELDS_WRK.APPR_VR_ROW = <scroll_info>;
Virtual_Router();
if None(APPR_INSTANCE) then
APPR_INSTANCE = APPR_FIELDS_WRK.APPR_INSTANCE;
endif;

The scroll_info is a number. If you’re calling the router from level 0, scroll_info is 0; if you’re
calling it from a scroll, scroll_info is the row number of the current row in the scroll. If you’re
calling from a level 1 to level 3 scroll, use the CurrentRowNumber() function.
 Chapter 2- Alternatives & Enhancements

1. We can also map OPRID to a work field OPRID to which we can assign a value on the
workflow event just before we call TriggerBusinessEvent () function. Please make sure to
include this work field on your page if you want it to appear in the ‘map field’ box above.
Typically, we fetch OPRID values one-by-one from a separate set-up page where we
maintain a list of approvers.
2. Further, any particular &ROLEUSER can also be fetched with the help of these 2 queries
under a set of conditions: -
SQLExec("select ROLENAME from ps_appr_rule_detl where appr_rule_set = :1 AND APPR_STEP =:2",
"APPROVAL RULE SET", &APPR_STEP, &ROLENAME);
SQLExec("select B.roleuser from ps_rte_cntl_ln A, ps_rte_cntl_ruser B where A.RTE_CNTL_PROFILE =
B.RTE_CNTL_PROFILE and A.rte_from_value >=:1 and A.rte_to_value<=:1and B.rolename=:2",
“BUSINESS UNIT” , &ROLENAME, &ROLEUSER);
3. For any approver, at least one field on the page should change its value (including
approval action) for trigger of workflow to next level.
4. SMTP server needs to be configured, otherwise we cannot use email/message option in
activity directly in the worklist item.
5. If I want to have 2 different pages in my activity, I can achieve that using 2 different steps-
say 1 for approve, other for deny
6. In ARS based workflows, if you untick 'approval active', virtual router doesn’t check the
ARS rules and request is approved fully as soon as saved. Further, if you tick 'self
approval’, it means you can approve your request but subjected to amount and quantity
rules.
7. ARS based workflows ultimately operate on triggerbusinessevent () only internally.
However, when we have requirements which are highly non-uniform in nature w.r.t.
routing of our workflow or approver options, we use the triggerbusinessevent () workflow
and customize it through peoplecode.
8. In ARS based workflows, if our requirement is a 3-level workflow (i.e. 3 approvers), we
may keep 4 roles or steps in the ARS and assign 2 roles to 1 of the approvers. This will be
a flexible design for future in case the no. of approvers goes up to 4 say for a different
business unit or route control profile.
9. The Route Control Queries (mentioned in ARS based workflows) can be studied or tested
from front end (Reporting Tools> Query> Query Manager).

TROUBLESHOOTING SOME COMMON WORKFLOW PROBLEMS

1. Check the ‘Worklist User’ checkbox in the Workflow tab of the userid in
Peopletools>security>user profiles before proceeding ahead.
2. Check the relevant role & route control profile of the user in case of approval rule set
based workflows.
3. Worklist item getting transferred but approval page not opening up component's search
record OPRID not getting updated- Check the SQL view query of the search record.
4. How to monitor my workflows(status/level of approval) from front end PeopleTools>
Workflow> Monitor Worklist> Update Worklist Entries.
 REFERENCES
- PeopleTools 8.44 PeopleBook: Workflow Technology

-- End of document --