PeopleSoft Workflow and Securitydocshare01.docshare.tips/files/7664/76646018.pdf · PeopleSoft Workflow and Security PeopleSoft workflow tools enable the definition of necessary rules

ClassPeopleSoft Workflow and Security1 Day Course[A comprehensive 2 day tour on the capabilities of the SQR language and its usage in PeopleSoft]

PeopleSoft Workflow and Security

Table of Contents

1.1 REVIEW AGENDA ......................................................................................... 3

1.2 PEOPLESOFT WORKFLOW TECHNOLOGY OVERVIEW .............................................. 3

1.3 THE 8 STEPS OF WORKFLOW DEVELOPMENT. ..................................................... 8

1.4 BUILDING WORKFLOW MAPS ........................................................................ 10

1.5 DEFINING ROLES AND USERS ......................................................................... 22

1.6 DEFINING WORKLIST RECORDS ...................................................................... 25

1.7 DEFINING EVENT TRIGGERS .......................................................................... 44

1.8 USING BATCH WORKFLOW PROCESSING ........................................................... 48

2.1 PEOPLESOFT SECURITY ............................................................................... 52

2.2 SECURITY ADMINISTRATION .......................................................................... 62

2.3 SETTING UP PERMISSION LISTS ...................................................................... 68

2.4 SETTING UP ROLES ..................................................................................... 80

2.5 ADMINISTERING USER PROFILES ..................................................................... 81

2.6 IMPLEMENTING QUERY SECURITY ................................................................... 81

2.7 DEFINITION SECURITY ................................................................................. 86

Page 2 of 90


1.1 Review Agenda

In this topic we will cover two areas

Workflow – workflow enables automation of flow of information

Security – to maintain and control access to system based on user class and usage

profile.

1.2 PeopleSoft Workflow Technology Overview

Many of the daily tasks performed by system users are part of larger tasks that

involve a number of steps and multiple people working together, often in a

predefined sequence. The term Workflow refers to the larger process, involving

several people, the activities required, and the routing of data between the

participants.

The most common workflow tools used are simply means of communication between

parties involved in the process. These communications often happen in the form of

telephone calls, transfer of physical (paper) files from one office to another, emails

or hand-written notes. These workflow media are easily deployed and the tools

mostly do not require any specific skills.

However, these kinds of systems rely on every participant in the chain knowing the

steps and players involved. If one participant has to be replaced with another

person, this knowledge has to be transferred onto the replacement. This can become

increasingly difficult in settings where the same person partakes in many workflow

processes, or when unforeseen short-term replacement needs arise. If the system

and procedures are not well documented, the likelihood of breaking the workflow

chain is high.

In addition, these manual systems have little to no control features. Often, a person

is not expecting to receive a particular item for processing from their workflow

predecessor. If the predecessor fails to complete their task in a timely fashion, it is

likely that no mechanisms are in place to remind them of the outstanding items.

Page 3 of 90


PeopleSoft workflow tools enable the definition of necessary rules and routings within

the system. These components are then used to tie together the individual activities

necessary to accomplish a complex task. With careful planning and configuration,

this infrastructure will deliver the right information

1.3 UNDERSTANDING PEOPLESOFT WORKFLOW:

The “3Rs” of Workflow

The corner stones of Workflow process automation within the PeopleSoft Student

Administration application are the “3Rs” – Rules, Roles, and Routing. These three

components work together to ensure that the organization’s business processes are

followed, that appropriate actions are taken in a timely manner in response to an

event, and that the right individuals in the organization become involved in the

process.

The following sections discuss each one of the 3Rs in more detail.

Rules – The What?

Workflow Rules capture the organization’s business processes and formulate them

using PeopleSoft Workflow tools. They determine the conditions to trigger a workflow

process; these conditions are also referred to as “Business Events”. Workflow Rules

also specify what activities are required to process data related to a given business

process, and the sequence of these activities.

Figure 1 shows an example for the visual representation of a Business Process.

Often, these visual representations are referred to as “Workflow Maps”.

Page 4 of 90


Figure 1 Sample Business Process

The icons represent activities in the overall business process. Arrows indicate

the flow of data and the sequence of activities involved. In this example, a two-level

approval process is triggered by generating a refund either online or through a batch

transaction.

The Rules are comprised of the conditions under which data flow must be initiated

(often this is the completion of the a predecessor activity), and the definition of the

follow-up activity. Each activity can in turn consist of multiple steps, possibly linked

by their own set of rules.

Figure 2 Sample Activity

Figure 2 shows the Quick Admit Process as a sample activity to illustrate the

composition of an activity as a collection of atomic steps. Steps are often tasks that

can be performed using a particular component or page in a PeopleSoft system.

Activities can also define a sequence of steps, Business Events, and Routing

specifications, as can be seen in Figure 3.

Figure 3 Sample Activity including a Business Event and Worklist Routing

Page 5 of 90


In this example, the completion of step “Refund Approval” triggers a Business Event

“Send for Approval” that performs the Routing of data to a Worklist. In essence,

Workflow Rules determine the tasks to be completed and their sequence.

Roles – The Who?

Roles describe how people fit into the Workflow. A Role is a class of users who

perform the same type of work, such as Undergraduate Recruiters or Cashiers.

Business Rules typically specify what role needs to perform a particular activity. For

example, a rule can say that the bursar must approve every student refund.

Roles direct the work to types of people rather than to specific individuals.

Identifying Roles instead of individual users makes workflow more flexible and less

maintenance intensive. Associating Roles with users makes it easy to ensure that

workflow users have the security privileges they need to access the pages where

they complete their work.

Roles remain stable, even as people change jobs.

Roles utilize the existing PeopleSoft security infrastructure. As such, Role definitions

used for Workflow can either make use of static User-to-Role relationships, or

employ query to select one or more Role users at the time of Workflow execution.

Routings – The How?

At the heart of each Workflow definition is a set of Business Events and the Routings

associated with them. Routings are instructions that tell the system to forward

information to the next step in the business process. They are the system’s means of

moving data from one place to another, from one activity to the next. Routings

specify information destination and formatting: worklist entries, email messages, or

electronic forms. In essence: Routings bring the flow into workflow.

When creating a routing, the type of routing, data recipients, and data to be sent are

defined. The data is usually a subset of the data from the step that is triggering the

routing. A mapping specifies how the data from the application page is packaged for

delivery to the routing destination.

Page 6 of 90


As mentioned previously, three basic Routing types exist:

Worklists

A Worklist is a list of the items awaiting an activity by a specific user. Users select

items from the list, and the system automatically displays the pages they need to

process each item.

Worklists are automatically created as items are routed to them. To define a worklist,

a worklist record definition and the appropriate routings must be created.

Email

With email routings, email messages can be sent to recipients in response to

business events. Messages can inform users that there is work to be done. It is

common and appropriate to define two routings for the same event: one that adds

an item to a user’s worklist, and one that sends email to tell the user about the new

worklist item. Another scenario with multiple routings for a single event could involve

a worklist item for one group of users and email message notification to another

group.

One advantage of email Routings is that the recipient does not have to be a

PeopleSoft application user. Email Routings can be sent to anyone who can receive

email through the mail system utilized by Workflow. The recipient simply has to have

a user ID (this does not require access to the application) and email address in the

PeopleSoft system.

Electronic Forms

With a form Routing, the system takes data from a PeopleSoft component or page,

enters it onto a third-party form, and mails the completed form to designated users

using the forms product’s mail capabilities. This Routing type is similar to an email

Routing with the object sent being a structured form instead of an unstructured

message.

The advantage of form Routings over email routings is that they can provide two-

way communication: The recipient of the form can make changes to it and send it

back to the PeopleSoft application.

Page 7 of 90


1.3 The 8 steps of workflow development.

This section discusses the steps required to build a workflow.

Step One: Designing a Workflow Application

Designing a workflow application can include three main steps:

1. Analyze and document your business requirements.

2. Diagram the process flow.

3. Document the workflow object attributes for business processes, activities,

steps, events, and email and worklist routings.

In the planning phase of your implementation, take advantage of all PeopleSoft

sources of information, including the installation guides, PeopleTools documentation,

and the PeopleBooks that are specific to your applications.

After clearly designing your workflow requirements, you can proceed to building the

workflow.

Step Two: Build Supporting Definitions

If the applications required for your workflow do not already exist, build the

definitions that you need for fields, records, pages, components, and menus.

Step Three: Create Workflow Maps

Create the workflow maps comprising the steps, activities, and business processes

required for your workflow as determined in step one.

Use PeopleSoft Application Designer to create graphical maps that represent your

business process. At this stage, you create maps only for the processes that are

involved in the underlying application; you add PeopleSoft Workflow-specific

elements to the maps when you define events and routings.

Step Four: Define Roles and Role Users

Page 8 of 90


Define the roles and the role users, including any Query roles, required for your

workflow.

To ensure that work flows to the correct person, you must determine who that

person is. You can find the right person using either Query roles or user list roles.

Step Five: Define Worklist Records

Create a record definition that will be used to store all of the application-specific

information for the worklist.

The worklist record determines which fields of information the system stores for each

work item, including the data needed to access the target page (the search keys for

the page) and any additional information that you want to display in the worklist

itself. Because different worklist entries can have different target pages and display

data, you need separate worklist records for the different types of entries that will

appear in the worklist.

Step Six: Define the Workflow Objects

This is the step in which you define the workflow application. You enter each of the

objects onto a business process definition in Application Designer as determined in

step one.

You will define the events and routings that make up workflow. Events and routings

are both objects on the workflow maps. To define these workflow objects, add the

icons to the map, linked to the step representing the page where the triggering

event occurs.

Step Seven: Define Event Triggers

Define the business rule in PeopleCode on the triggering application record definition.

Workflow programs are defined on a record definition for one of the tables that the

component accesses. They contain the business rules used to decide whether to

trigger the business event. The PeopleCode detects when a business rule has been

triggered and determines the appropriate action.

Step Eight: Test

Test your workflow, or use the workflow monitoring tools in Workflow Administrator

to validate worklist routing results.

Page 9 of 90


1.4 Building Workflow Maps

Workflow maps: also known as Navigator maps, are visual representations of your

organization's business processes. Maps are necessary to all workflow processes, and

they can also be used as navigational aids for end users.

Workflow maps, also known as PeopleSoft Navigator maps, are visual

representations of your organization's business processes. Maps are necessary to all

workflow processes, and they can also be used as navigational aids for users.

There are two types of workflow maps, each representing a different hierarchical

level. The top-level map, known as a business process, represents broad areas of

functionality. Business processes contain one or more activities, or subprocesses.

Activities contain individual steps that represent the specific transactions that

complete that activity.

PeopleSoft Navigator: is an alternative to the standard portal navigation. With

PeopleSoft Navigator, users can see workflow maps and use them to access pages

(but not external programs) that are represented within these maps.

PeopleSoft Navigator presents maps according to their hierarchical relationships.

Users can browse the available maps and navigate to individual pages by clicking the

step that represents the page. As users move from map to page and back to map,

the Navigator tree remains visible on the left-hand side of the screen:

Page 10 of 90


PeopleSoft Navigator

• You control which maps are visible in PeopleSoft Navigator by defining a

Navigator homepage: a top-level business process that greets the user when

PeopleSoft Navigator is first accessed. Users can access only the maps that

are hierarchically related to this homepage.

Map Hierarchies

PeopleSoft Workflow uses three hierarchical levels. The first two levels, business

processes and activities, are both maps: graphical representations of the

relationships between the component objects (other maps or steps).

The third level, steps, are not maps. Steps are elements within activities and

represent the level at which the user interacts directly with application pages.

Business processes and activities are both freestanding definitions that you can open

in PeopleSoft Application Designer and include in projects. Because business

processes include icons for other maps (activities or other business processes),

create these lower-level maps before you add them to a business process. You can

develop in a top-down approach by creating the lower-level maps from the Business

Process Designer directly.

Steps are not freestanding definitions in PeopleSoft Application Designer; they exist

only within a particular activity. You create steps as you define an activity.

Map Icons

The following table presents the basic map elements.

The Business Process icon represents a complete business task, consisting of one or more

activities. Business processes can include other business processes. Normally, you use this

functionality only when designing maps for use in PeopleSoft Navigator.

The Activity icon represents a subprocess of the business task, consisting of one or more

steps.

The Step icon represents a discrete step in the business process, corresponding to a single

transaction performed on an application page or through an external program.

Business Processes

Page 11 of 90


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.

Activities

Activities that are intended only for end users (in PeopleSoft Navigator or in activity

guides) typically include only steps that correspond either to application pages or to

external programs.

When you incorporate workflow, activities also include events and routings. Events

represent specific transactions that can occur in the page that is connected to the

event. Routings represent notifications that are triggered by that event.

For example, there are several possible events on a page where managers approve

orders. The manager can approve or deny the order or send the order back to the

employee for changes. Each event requires routings to inform the next person in the

chain (a buyer, an additional approver, or the employee who submitted the original

order) about what must happen next.

The following map shows an activity with workflow routings:

Activity with workflow routings

Defining Maps

Page 12 of 90


This section provides an overview of map definition, lists common elements, and

discusses how to:

• Create a new map.

• Define business process properties.

• Define activity properties.

Creating a New Map

To create a new map:

1. In PeopleSoft Application Designer, select File, New.

2. In the New scrolling list, select the map type: Activity or Business Process.

3. Click OK.

4. Add the icons required to represent the activity or business process.

If you’re creating a business process, the icons represent other maps,

activities, and possibly other business processes. When you add these types

of icons to the map, you can specify an existing activity or business process

that the icon represents, or you are prompted to create a new one.

Even if you do not save the business process on which you are working, the

new activities or business processes that you created are saved to the

database. Arrange the icons in a logical and visually informative way.

If appropriate, add modeling symbols, drawings, arrows, text, or other

graphic elements to the map. These elements are useful primarily in maps

that are visible in PeopleSoft Navigator. They do not affect workflow

processing, nor are they visible in activity guides.

5. Connect the activities, decision points, and subprocesses in the appropriate

order:

a. Click the Link button.

b. Click the two objects sequentially.

An arrow appears, pointing from the first object to the second.

Page 13 of 90


The links between steps only clarify the flow of work. They do not

directly determine the order of the steps, which you specify when you

set the properties for individual icons in the maps. However, if you've

enabled automatic sequencing in the activity properties, the default

step order is based on the links.

6. Define the properties of the map.

7. Define the properties of the icons on the map.

8. Save the map.

Defining Business Process Properties

To define the properties of a business process:

1. Open the business process in PeopleSoft Application Designer.

2. Open the Business Process Properties dialog box:

a. Right-click in the map (but not on an item in the map).

b. Select Definition Properties.

The General tab in the Business Process Properties dialog box appears.

3. Set the properties on the General tab.

4. Set the properties on the Use tab.

A Navigator homepage is the high-level business process that a user sees

immediately after accessing PeopleSoft Navigator. A user's homepage settings

are established on the User Profile and Permission List pages. To make this

business process available as a homepage, select the Can be used as a

Navigator home page check box.

5. Click OK to accept the settings.

6. Save the business process.

Defining Activity Properties

To define the properties of an activity:

1. Open the activity in PeopleSoft Application Designer.

Page 14 of 90


2. Open the Activity Properties dialog box.

a. Right-click in the map (but not on an item in the map).

b. Select Definition Properties.

The General tab in the Activity Properties dialog box appears.

3. Set the properties on the General tab.

4. Set the properties on the Use tab.

The Use tab includes options for automatically sequencing steps and for

enabling end-user-facing activity guides.

After you add steps to an activity, arrange them into a logical sequence using

connecting arrows, and assign each step a number. If you select

Automatically sequence steps, the step numbers are automatically assigned

when you save the activity. The step numbers are based on the order in

which you connect the arrows. This is an efficient way to order the steps.

Select Activity Guide if you’re creating a map to use as the basis for an end-

user-facing activity guide.

5. Click OK to accept the settings.

Adding Map Objects

This section provides an overview of toolbar buttons and discusses how to:

• Add icons to maps.

• Connect icons within a map.

• Add images to maps.

• Arrange objects on maps.

• Set icon properties.

• Control text.

• Add drawing shapes to maps.

• Use other map display features.

Page 15 of 90


Understanding Toolbar Buttons

Use toolbar buttons to add icons and connecting lines to maps. Different toolbars

(and therefore different map objects) are available for business processes and

activities.

Business Process Toolbar

This toolbar provides the basic components of a business process, including activities

and the lines that link them. This toolbar is visible only when a business process is

the active window.

Click the Link button to connect related activities or steps. This button is also in

the Activity toolbar.

You must use the link tool to connect objects on the map; do not use arrows or

other drawn shapes.

Click the Business Process button to add another business process.

Click the Activity button to add an activity.

Click the Decision button to add a decision point in a process. A Decision icon in

a map is descriptive only; it has no workflow functionality. This button is also in

the Activity toolbar.

Activity Toolbar

This toolbar provides the basic components of an activity, including steps, workflow

events, and workflow routings. This toolbar is visible only when the active window

displays an activity.

Click the Link button to connect related activities or steps. This button is also in

the Business Process toolbar.

Click the Step button to add a PeopleSoft page.

Click the Event button to add a business event.

Click the Worklist button to add a worklist.

Click the Email button to add email for workflow routing.

Click the Batch button to create a descriptive icon for a background process.

Click the Manual Process button to create a descriptive icon for a manual

Page 16 of 90


process.

Click the Decision button to create a descriptive icon for a decision point in a

process. This button is also in the Business Process toolbar.

Click the Local Transaction button to create a descriptive icon representing an

application message definition for a transaction that occurs in one database.

Click the Transaction other DB (transaction other database) button to create a

descriptive icon representing an application message definition for a transaction

that sends a message to another database in the same enterprise.

Click the Remote Transaction button to create a descriptive icon representing an

application message definition for a transaction that sends a message to another

database in another enterprise by crossing the firewall. Application message

definitions are used in PeopleSoft Integration Broker transactions..

Events and Routings Icons

These are actual workflow objects, representing transactions that trigger workflow

(events) and the medium through which the trigger sends work to the recipient

(routings). You normally add these objects to activities after completing the basic

maps.

The following graphic presents the events and routings icons:

Events and routings icons

Adding Icons to Maps

To add an icon to a map:

1. Click the toolbar button representing the icon that you want to add.

2. Click the map where you want to place the icon.

Page 17 of 90


In most cases, the icon is added to the map when you click. If you're adding

an icon for an activity, business process, or transaction, however, the Select

Definition dialog box appears.

3. In the Select Definition dialog box, select the specific activity, business

process, or application message definition that the icon represents.

4. Click the Select button to finish placing the icon on the map.

Connecting Icons Within a Map

To connect icons within a map:

1. Click the Link button on the toolbar.

You must use the link tool to connect icons; do not use arrows or other

drawing objects.

2. Click the icon where the link starts.

The icon must be a linkable definition. As you pass the cursor over different

parts of the map, its appearance changes to indicate whether you’re over a

linkable definition:

• A plus sign indicates that you are not over a linkable definition.

• A plus sign within a circle indicates that you are over a linkable

definition.

3. Click the icon where the link ends.

This click completes the link, and an arrow from one object to the other

appears. Even if you relocate objects on the map, the link stays connected to

both objects.

To cancel without completing the link, right-click.

4. (Optional) Modify the shape of the link.

To create angles at the same time that you create the link, make one or more

intermediate clicks where you want the line to bend. You can add multiple

angles. However, you must always end the line with a linkable definition.

Page 18 of 90


Change the angle by clicking the connector line, selecting the angle anchor,

and moving it.

To create an angle in an existing link, select the link, press and hold the CTRL

key, and click where you want to create an angle anchor. You can then move

the anchor as described previously.

Understanding Descriptive Icons

Both business processes and activities can include descriptive icons. These icons

typically do not have associated workflow processing; they are useful primarily if the

map will be visible through PeopleSoft Navigator.

Setting Properties for Descriptive Icons

To set properties for descriptive icons:

1. Right-click the descriptive icon and select Item Properties.

The Properties dialog box appears. Depending on the type of icon, the title

bar reads Business Processes Definition, Activity Definition, or Description

Symbol Definition.

2. Enter information in the dialog box.

The text that you enter in the Name field identifies the icon and, by default,

appears as the display text under that icon. To display different text under

the icon, enter it in the Icon Descr text box. Include line breaks in the text by

pressing the ENTER key.

3. Click OK to close the dialog box.

Setting Properties for Step Icons

Set properties for the steps in an activity to associate the step with the proper page

or external program and to establish the correct sequence of steps within the

activity.

To set properties for step icons:

1. Right-click the step icon and select Item Properties.

The Step Definition dialog box appears.

Page 19 of 90


2. Enter descriptive information about the step.

3. Enter the step and path numbers to place this step into the activity’s flow.

The Step Number and Path Number boxes order the steps in this activity.

When the user always completes the same steps in the same order, specify

the order of the step in the Step Number box and leave the number 1 in the

Path Number box. The first step is step 1; the second is step 2.

When the user performs different tasks along the way, define multiple step

paths. Start numbering the steps from step 1, staying on path 1 until you

reach the first point at which a user has options. For each step that might

come next, use the next consecutive step number, but a different path

number, for each one. All of the steps should have the same step number

sequence, but a different path number value.

If a user-facing activity guide based on this map is available, you might want

to make the more common path the default path. Select Default Step for the

step that you want the activity guide to take when a user progresses through

the activity.

You can avoid the manual sequencing of steps if you use the automatic step

sequencing options that are available in the property sheet for the activity.

However, always review the sequence created by automatic numbering to

verify that the sequence is correct.

4. (Optional) Click Activity Guide.

This button is available only if you have marked this as an activity guide in

the activity properties. The Step Internet Client Attributes dialog box appears.

If this map is an activity that will be used in an activity guide, enter the

necessary information in this dialog box.

Setting Step Attributes

Page 20 of 90


This section discusses how to set step attributes.

Use the Step Attributes dialog box to select the page or program that the system

starts when a user selects this step and the action mode that is used to open the

page.

To set step attributes:

1. On the Step Definition dialog box, click the Attributes button.

2. Specify whether the user completes this step on a PeopleSoft page or from an

external program.

When you select Page or External Program, the appropriate section of the

dialog box becomes available. If this is an activity guide and you’ve marked

the activity guide option in the activity properties, you must select Page.

3. Provide directions for starting the page or external program.

If a user performs the step by completing a PeopleSoft page, select the page

from the list boxes in the Processing Page group box.

In the Actiondrop-down list box, select the type of activity that the user must

perform on the database: Add,, Update/Display, Update Display/All, or

Page 21 of 90


Correction. When a user selects this step, the system displays the specified

page in the specified action mode.

If users perform the step using an external program, select the program

name and its working directory from the External Program group box. The

program name must be the name of the executable file, followed by

command line parameters, if appropriate. When a user selects this step, the

system starts the specified program.

4. Click OK in the Step Attributes dialog box.

5. Click OK to close the Step Definition dialog box.

1.5 Defining Roles and Users

This chapter provides an overview of roles and users and discusses how to:

• Define a role query.

• Maintain roles and role users.

You can define a role as a fixed list of individual role users or as a query that selects

one or more role users at runtime.

This section discusses:

• User list roles.

• Query roles.

• Route controls.

• Case study: the manager query role

Page 22 of 90


User List Roles:

PeopleSoft delivers a set of default user-list roles corresponding to the levels within

an organization, such as EMPLOYEE, MANAGER, and VICE PRESIDENT. These roles

are intended primarily for use with route controls.

Use the following criteria to determine how to define a role:

• It doesn’t matter which person performs the work that is assigned to the role.

For example, if a training clerk enrolls employees in classes, the TRAINING

CLERK role can be defined as a list of users, because it doesn’t matter which

clerk enrolls an employee in a class. The system forwards enrollment requests

to the worklist for training clerks, and the first clerk who selects the request

handles it. (In PeopleSoft Workflow terminology, the users are working from a

pooled worklist.)

• You want everyone who fills the role to receive the same set of work items.

For example, if you want the automated Worklist Monitor to send email

messages to several people when worklist volumes become too high, you can

route messages to a role called SYSTEM ADMINISTRATOR. Every

administrator receives the messages.

• Only one person fills the role.

For example, the CHIEF FINANCIAL OFFICER role can be a user list, even

though the list is very short.

Query Roles:

Define a role as a query if you want to send work items to different people at

different times. When an employee’s manager must approve a training request, the

manager role is a query, because you want to send enrollment requests to different

managers, depending on who makes the request.

When a role is defined as a query, the system determines who should receive a work

item based on the values of fields on the page that triggers the routing. It uses

context information from the current record to determine who needs to complete the

work. For example, the manager role query uses the value of the Employee ID field

from the course request to look up the name of the employee’s manager.

Page 23 of 90


Because of the flexibility they bring to business processes, query roles are more

common than user list roles.

When you create a query role, you tell the system how to determine who fills the

role at runtime. You don’t need to assign role users to the role, as you do with user

list roles. However, you must set up the query by:

1. Writing a query in PeopleSoft Query. The query identifies the users to whom

the work item is routed. The query must take a value from the page that

triggers the event, such as the user’s user ID or employee ID, and return a

list of role users.

2. Defining the role through PeopleSoft Security Administration. For query roles,

you pick the query that you want to run.

3. Assigning the role to the appropriate workflow routings. Because the query

has runtime bind variables, you must also specify which page field values to

copy into the query.

Route Controls:

The PeopleSoft Workflow Administrator enables you to define route controls. For

example, suppose that you want to route purchase 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.

Page 24 of 90


1.6 Defining Worklist Records

This topic provides an overview of worklist records and discusses how to:

• Create worklist record definitions.

• Replicate worklists.

The Worklist:

The worklist can include several different types of items at once. For example, a

manager might have entries related to approving both employee course enrollments

and orders for supplies.

Although both types of entries appear in the manager’s worklist, the underlying data

is different. The course enrollment entries might display information about the

course name and start date, while the orders might have information about the

descriptions and prices of ordered items.

Worklist Records:

Entries in worklists are stored in database tables. You define the structure content of

these tables by creating worklist records. The 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.

The basic procedure for creating a worklist record definition is the same as for any

record definition, but worklist record definitions have some special requirements.

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).

Page 25 of 90


• Display relevant information about each work item on the Worklist page so

that users can select the item on which they want to work.

• 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 are 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 that:

Page 26 of 90


• 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.

• Application field names cannot be the same as key words used in field

mapping.

• 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. These fields are optional.

Worklist Display

Field

Description

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

Page 27 of 90


Creating Worklist Record Definitions:

To create a worklist record definition:

1. In PeopleSoft Application Designer, add the required system fields to the

record definition.

Identify the required system fields as key fields with ascending sort order.

2. Add the key fields from the search record for the page that group users use to

process the worklist entries.

The worklist record must include the search record key fields so that the

system can locate the record on which the user must work.

3. (Optional) If users work on work items using an external program, rather

than a PeopleSoft page, add a character field named COMMAND_PARM.

When you define a step in an activity, you can specify that an external

program starts when a user selects it. If the activity assigned to this worklist

starts with such an activity, you can pass command-line arguments to the

external program from the worklist record.

For example, if you map a filename to the COMMAND_PARM field, the system

appends the file name to the external program’s command line (as specified

in the step definition).

4. Add fields to provide descriptive information in the user’s worklist.

If you have a compelling reason, you can add other application fields instead.

However, don’t add other application fields if you’ve added the

WORKLIST_DESCR field, because using WORKLIST_DESCR automatically

stops the worklist from displaying the application fields.

5. Save the record definition using a name that ends with _WL.

6. Create a database table using the record definition that you saved in step

5.1.8: Adding Events and Routings:

This chapter provides an overview of events and routings and discusses how to:

• Add and define events

• Add and define worklist routings.

Page 28 of 90


Events and Routings

When you create a business process in PeopleSoft Application Designer, you specify

which activities form a business process and in what order they must be completed.

The map provides an overview of the process, but it doesn’t provide a link between

the activities. To link the activities to a workflow, you add routings, which automate

the delivery of information to other activities and other users.

Events are conditions that have associated routings. Define the condition in

PeopleCode, which is attached to the record definition underlying a step in a step

map. When a user saves the page, completing the step, the system runs the

PeopleCode program to test the condition. If the condition is met, the system

performs the routings.

Routings can deliver data in two forms: worklist entries and email messages. To

create a routing, specify the routing type, who should receive the data, and which

data you want to send. The data is usually a subset of the data from the step that

triggers the routing.

Adding and Defining Events:

Add and define events in PeopleSoft Application Designer.

This section discusses how to:

• Add an event

• Define the event

• Edit the business rules

Adding an Event:

To add an event:

1. Open the activity to which you want to add the event.

2. Click the Event button in the toolbar.

3. Click where you want the event to appear on the map.

The Event icon appears on the map.

4. Connect the Event icon to the icon for the step that triggers it.

a. Click the Connector icon in the palette.

Page 29 of 90


b. Click the Step icon, then the Event icon.

An arrow connects the two icons.

Use the Link icon, not the Line icon, to connect an event to the step

that triggers it. If you use the Line icon, the system won’t recognize

the event.

Defining the Event:

To define the event:

1. Double-click the Event icon, or right-click and select Item Properties.

The Event Definition dialog box appears.

2. Enter a name and description of the event.

Name Enter the name used to trigger the event with the

TriggerBusinessEvent PeopleCode function. By default, the event

name also appears as the display text under the icon on the map.

Active When an activity triggers an event, the TriggerBusinessEvent

function determines whether the event is active. To temporarily

deactivate an event, preventing any of its routings, clear this check

box. To restart an inactive event, select it.

Event

Triggered from

Record Name

Select the record definition to which you want to add Workflow

PeopleCode to trigger the business event

Editing the Business Rules

To edit the business rules:

1. Click the Edit Business Rules button.

The PeopleCode Editor appears. The name of the first key field in the specified

record definition appears in the title bar.

2. Enter the PeopleCode that triggers the business event.

3. Save the PeopleCode.

4. Click OK to close the Event Definition dialog box.

Page 30 of 90


Adding and Defining Worklist Routings:

This section discusses prerequisites to defining worklist routings and discusses how

to:

• Create worklist routings.

• Define worklist attributes.

• Specify field mappings.

Before you create a worklist routing for an activity, create a worklist record

definition. The worklist record determines what fields the system stores for each

work item.

Creating Worklist Routings:

To create a worklist routing:

1. Create the business event that triggers the worklist routing.

2. Click the Worklist button on the toolbar.

3. Click where you want the Worklist icon to appear on the map.

The Worklist icon appears.

4. Connect the worklist routing to the event that triggers it.

a. Click the Connector icon in the palette.

b. Click the Event icon, then the Worklist icon.

An arrow connects the two icons. Use the Link icon to connect a

routing to an event. If you use the Line icon, the system won’t

recognize the routing.

5. Double-click the Worklist icon, or right-click and select Item Properties.

The Worklist Definition dialog box appears.

6. Enter a name and description for the worklist routing.

Defining Worklist Attributes:

Define worklist attributes on the Worklist Attributes dialog box

Page 31 of 90


To define worklist attributes:

1. On the Worklist Definition dialog box, click Attributes.

The Worklist Attributes dialog box appears.

2. Select the worklist record, business process, and activity from the appropriate

drop-down list boxes.

Worklist

Record

Select the record definition to use for storing and displaying work items.

Business

Process

Enter the business process name that is associated with the worklist

item.

Activity Enter the activity name that is associated with the worklist item. When a

user selects a work item from the worklist, the system displays the page

(or external program) that is associated with the first step in the activity

that you specify here. The first step is the one marked as Step 1 Path 1

in the step map.

You usually select the next activity in the current business process, but

this is not required. You can route to any activity in any business

process. This is the “Worked by” business process and activity, which

may not be the same as the business process or activity that triggered

Page 32 of 90


the worklist.

3. Select worklist page attributes.

Pooled List Specifies whether the system creates a single shared work item or

one work item for each worklist user. With a pooled worklist, all

worklist users receive copies of shared work items; the first user

who selects an item works on it, and the item is dropped from

everyone else’s worklist. With a non-pooled worklist, each user

receives a personal copy of each item.

If Delete Pooled WL When Select is selected on the Worklist System

Defaults page, a pooled worklist will be deleted from other queues

when a user selects it.

Timeout

Processing

Active

Specifies whether the system checks this worklist for overdue

items.

Reassignable Enables users to reassign worklist items to other users.

4. Specify the timeout parameters (if timeout processing is active).

Timeout

Parameters

Specifying a timeout condition is optional. If you want all work items

to remain in this worklist until a user processes them, leave the

controls in this group box blank, or clear the Timeout Process Active

check box. Otherwise, specify how long to wait (days, hours, and

minutes) for a user to process a work item. The system adds the

three values together. If a work item sits in the worklist for longer

than the specified amount of time, the system performs the action

identified by the check box that you select.

Email

Assigned

Current User

Send an email message to the user to whom the work item is

assigned, warning that the item is overdue.

Email

Supervisor

Send an email message to the user’s supervisor. The supervisor is

assigned as the user’s supervising role user in the user profile,

maintained through PeopleSoft Security. In PeopleSoft HRMS

applications, the system uses the supervisor from the user’s

PERSONAL_DATA record.

Send Timeout Send a new worklist item to the currently assigned user’s timeout

Page 33 of 90


Worklist worklist.

5. Specify what the user must do before the system considers a work item to be

worked.

Work items remain in a user’s worklist until they have been worked.

User Specified A work item is marked as worked when the user explicitly identifies it

as worked by selecting it on the Select Worklist page and clicking the

Mark Worked button. This option is useful when the user must return

to the same work item several times or wait for supporting

information.

If the worklist item is replicated from another database, the Mark

Worked function is disabled in the target database.

Saved A work item is marked as worked when the user saves work on the

page that is assigned to the worklist. This option is appropriate for

work items that the user can complete right away.

Selected A work item is marked as worked as soon as the user selects it from

the worklist. This option is appropriate for work items that notify the

user of an event; just seeing the item is sufficient.

Programmatic A work item is never marked worked directly by the user. It can be

marked as worked only with PeopleCode. This setting enables you to

provide additional logic to determine when a work item can be

considered worked.

6. Click OK to close the Worklist Attributes dialog box and return to the Worklist

Properties dialog box.

Specifying Field Mappings:

Specify field mappings on the Field Map dialog box.

Page 34 of 90


To specify field mappings:

1. Click the Field Mapping button.

If the Field Mapping button is unavailable, you haven’t properly linked the

routing to the event that triggers it.

The Field Map dialog box appears. Use this dialog box to tell the system

where to find the data to create a worklist entry. The Message Map group box

lists the fields involved.

Name Displays the user ID (OPERID) of the person who receives the worklist routing.

It may also display the fields in the worklist record, which includes key data

Page 35 of 90


for the page where the user performs the necessary work and the descriptive

data that appears in the user’s worklist—normally the WORKLIST_URL and

WORKLIST_DESCR fields.

Mode Specify the map mode value from Copy, Xlat-S, or Xlat-L (use one of these

two values if the field has a translate table value).

Value Indicates where the system finds the data to enter into those fields.

2. Select the field to which you want to map a value.

3. Click the Change button, or to add a new field to the map, click the Add

button.

4. The Map Field dialog box appears. Use this dialog box to provide a value for

each field in the worklist record.

5. Select the field into which you want to place routing data.

If you select the field from the message map, its name appears in the Field

list box. If the correct name doesn’t appear, you can select a field from the

list box or enter a new name.

6. Identify the value for the selected field.

There are three ways to put data into a field: from a database field, a specific

constant value, or a role name.

Record

Field Value

To enter the value from a database field into the worklist field, select the

RecField option. The Record box lists the record definitions that should

be available when the event triggers this routing (according to the page

and record definition associated with the event). Select the record name.

The fields in that record appear in the Fields list box. Select the field

whose value you want. When the event is triggered, the system

completes the worklist field with the value of the field in the current

record.

Constant To assign a specific constant value to the field, select this option and

enter the value in the text box to the right. Every worklist entry will

have this value in the selected field.

Role Name To assign a role name to the field, select this option and select a role

from the drop-down list box that appears next to it. When the event is

triggered, the system completes the field with a list of users who fill this

Page 36 of 90


role. If you select a user list role, each user who is assigned to that role

receives a copy of the work item. If you select a query role, each user

that the query returns receives a copy.

7. If you map the field to a role name, provide values for any bind variables.

If you map the user ID field to a query role that includes bind variables, the

Specify Query Bind Variables button appears next to the Role Name option.

When you click this button, a dialog box appears, enabling you to specify the

value that each bind variable in the query should take for each work item.

The Query Bind Variable column displays the bind variables for the role query.

(If nothing appears in this column, you defined the query without specifying

any bind variables.) The Record column lists the record definitions associated

with the component that triggers this routing. The Field column displays the

fields in the selected record definition.

You can bind each variable with the value from a record field or with a

constant:

• To bind a variable with the value from a record field, select the Field

option, select the bind variable for which you want to provide a value,

and select the record field to contain the value.

• To bind a variable with a constant, select the Constant option, and

enter the value into the text box.

8. When you’ve mapped bind values for all of the variables, click OK to close the

dialog box.

9. If you map the field to a record field, specify whether the system copies the

assigned value directly into the worklist field or replaces the assigned value

with a value from the translate table.

Select the appropriate option from the Map Mode list box. This list box is

available only if the selected field has associated translate table values. In

most cases, leave the default value (Copy).

For example, suppose the worklist record definition includes an Employment

Status field, and you associate the field with the record field

PERSONAL_DATA.STATUS. If the PERSONAL_DATA.STATUS field holds an

Page 37 of 90


abbreviation that translates to a value in the translate table, you can tell the

system to populate the worklist field with the abbreviation (Copy) or with the

corresponding translate table value (Xlat-S for the short form or Xlat-L for the

long form).

10.Click OK to add the field and its value to the routing dialog box.

11.Repeat steps 5 to 10 for each field that you want to add to the worklist

routing.

You must provide values for all of the key fields in the worklist record

definition.

12.Close all of the dialog boxes by clicking OK in each one.

Adding and Defining Email Routings:

This section provides an overview of email routings and discusses how to:

• Create an email routing.

• Map fields.

With email routings, you can send email messages in response to business events. In

some cases, you might want to define two routings for the same event: one that

adds an item to someone’s worklist and one that sends an email message to tell that

person about the new worklist item.

You can send an email routing to anyone to whom you can send email messages

through the mail system. PeopleSoft applications support email routings to any email

software that supports the Simple Mail Transfer Protocol (SMTP) standards.

Creating an Email Routing:

To create an email routing:

1. Create the business event that triggers the email routing.

2. Click the Email button on the toolbar.

3. Click where you want the Email icon to appear on the map.

The Email icon appears.

4. Connect the email routing to the event that triggers it.

Page 38 of 90


a. Click the Connector button in the palette.

b. Click the Event icon, then the Email icon.

An arrow connects the two icons.

5. Use the Link icon to connect a routing to an event.

If you use the Line icon, the system won’t recognize the routing.

6. Double-click the Email icon, or right-click and select Item Properties.

The Email Definition dialog box appears.

7. Enter a name and description for the routing. By default, the routing name

also appears as the display text under the icon on the map.

8. Select any settings to apply to the email message.

The options in this dialog box correspond to the mailing options offered in

most email software. If your email software does not support one or more of

these options, the system ignores its setting.

See See the documentation for your email software.

9. Click to return to the Email Definition dialog box.

Mapping Fields:

Page 39 of 90


To map fields:

1. Select Field Mapping.

2. The Field Map dialog box appears.

Use this dialog box to tell the system where to find the data to create an

email message. The Message Map group box lists the fields involved.

Name Displays the fields.

Value Indicates where the system finds the data to enter in the fields.

The fields that appear in this dialog box represent the two different types of

data that are needed to create an email message: who and what. That is:

• Who receives the email message?

The TO field holds the email address for this person.

• What is the content of the email message?

This includes a SUBJECT line and any additional text that you add. You

can also concatenate data into the message. When you first open the

dialog box, the Name column displays the fields available for mapping.

You must provide a value for the TO field.

3. Select the field into which you want to map a value.

4. Click the Change button, or to add a new field to the map, click Add.

Page 40 of 90


5. The Map Field dialog box appears.

Use this dialog box to create the email message from the values provided by

the step that triggers the routing.

6. Select the field into which you want to place routing data.

If you select the field from the message map, its name appears in the Field

list box. If the correct name doesn’t appear, you can select a field from the

list box or enter a new name.

The following fields in an email routing’s message map have specific

meanings to the email software to which the system forwards the email

message.

TO Indicates the name of the person to whom you want to send the email

message. The value can be an email name or a role. To send to more

than one person, separate the names with semicolons. The values in the

TO, CC, and BCC fields determine who receives the email message. The

values that you map to these fields can be email addresses, role user

IDs, or role names. The system automatically converts role user IDs and

role names into the users’ email addresses.

FROM (Optional) Indicates the email address of the sender. Setting this value

overrides the system SMTPSender value so that the recipient of the

email message can reply to an individual, rather than to the system

email address.

REPLYTO (Optional) Indicates the email address to which the sender recommends

sending replies.

SENDER (Optional) Indicates the email address of the actual originator of the

email if different from the address set in the FROM field.

CC and

BCC

(Optional) Indicates the names of other people to whom you want to

send the message.

SUBJECT Indicates the subject line that appears in the receiver’s email inbox.

NOTETEXT Indicates the body of the message. The message can have multiple

NOTETEXT fields. The system displays NOTETEXT fields in the order in

which they appear in the Field Map dialog box.

1. To add a new NOTETEXT line, click the Add button in the Field Map dialog

box.

Page 41 of 90


2. Select NOTETEXT in the Field Name box.

FILEPATH (Optional) Indicates the completed qualified path and filename for a file

to attach to the email message.

FILENAME (Optional) Indicates the name to display in the body of the email

message, below the icon that represents the file attachment.

FILETYPE (Optional) Indicates the type of file being attached.

3. Identify the value for the selected field.

The value can be data from a record field, a specific constant value, or a role

name.

Record

Field Value

To enter the value from a record field into the email message, select the

RecField option. The Record box lists the record definitions that should

be available when the event triggers this routing (according to the page

and record definition associated with the event). Select the record name.

The fields in that record appear in the Fields list box. Select the field

whose value you want. When the event is triggered, the system

completes the email field with the value of the record field in the current

record.

Constant To assign a specific constant value to the field, select this option and

enter the value in the text box to the right. Every email message will

have this value in the selected field.

Role Name To assign a role name to the field, select this option and select a role

from the drop-down list box that appears next to it. When the event is

triggered, the system completes the field with a list of users who fill this

role. If you select a user list role, each user who is assigned to that role

receives a copy of the email message. If you select a query role, each

user that the query returns receives a copy.

Although the role returns a list of role users, the system enters the

user’s email address into the field. There must be an email address in

each role user record.

4. If you map the field to a role name, provide values for any bind variables.

If you map the TO, CC, or BCC field to a query role that includes bind

variables, the Specify Query Bind Variables button appears next to the Role

Page 42 of 90


Name option. When you click this button, a dialog box appears, enabling you

to specify the value that each bind variable in the query should take.

The Query Bind Variable column displays the bind variables for the role query.

(If nothing appears in this column, you defined the query without specifying

any bind variables.) The Record column lists the record definitions associated

with the component that triggers this routing. The Field column displays the

fields in the selected record definition.

You can bind each variable with the value from a record field or with a

constant:

• To bind a variable with the value from a record field, select the Field

option, select the bind variable for which you want to provide a value,

and select the record field that will contain the value.

• To bind a variable with a constant, select the Constant option, and

enter the value into the text box.

When you’ve mapped bind values for all the variables, click OK to close

the dialog box.

1. If you map the field to a record field, specify whether the system copies the

assigned value directly into the field or replaces the assigned value with a

value from the translate table.

Select the appropriate option from the Map Modedrop-down list box. This list

is available only if the selected field has associated translate table values. In

most cases, leave the default value (Copy).

For example, suppose that you want to include a person’s employment status

in the email message, so you associate the NOTETEXT field with the record

field PERSONAL_DATA.STATUS. If the PERSONAL_DATA. STATUS field holds

an abbreviation that translates to a value in the translate table, you can tell

the system to populate the field with the abbreviation (Copy) or with the

corresponding translate table value (Xlat-S for the short form or Xlat-L for the

long form).

2. Click OK to add the field and its value to the routing dialog box.

3. Repeat steps for each field that you want to add to the routing.

Page 43 of 90


4. Close all of the dialog boxes by clicking OK in each one.

1.7 Defining Event Triggers

This chapter provides an overview of event triggers and discusses how to:

• Write Workflow PeopleCode.

• Write PeopleCode for approval processes.

• Use additional PeopleCode functions and variables.

As you define workflow processes, you identify the application pages that trigger

business events. Then you must add PeopleCode programs to the pages so that they

actually trigger the events. The PeopleCode detects when a business rule has been

triggered and determines the appropriate action.

This section provides an overview of Workflow PeopleCode and discusses how to:

• Use the TriggerBusinessEvent function.

• Create Workflow PeopleCode programs.

Workflow PeopleCode

To trigger a business event from a page, you add a PeopleCode program to the

workflow event in the record definition for one of the tables to which the page writes.

For example, to trigger events from the Course Request page, add Workflow

PeopleCode to the TRAINING record definition; TRAINING is the record definition

with which the Course Request page fields are associated.

If you’re triggering business events from a page that includes scrolls, add the

Workflow PeopleCode to the record definition at the appropriate scroll level. If, for

example, you add it to the record definition that is associated with a level one scroll

area, the PeopleCode runs once for each row at that level. A Workflow PeopleCode

program can reference record fields from record definitions at the same scroll level

or at a lower scroll level. These rules also apply to the SaveEdit PeopleCode for

Virtual Approver.

Page 44 of 90


Workflow PeopleCode runs after the user saves the page group and before it updates

the database with the saved data. More specifically, it runs after SavePreChange

PeopleCode and before SavePostChange PeopleCode. Because SavePostChange

PeopleCode runs after Workflow PeopleCode, it does not run if the Workflow

PeopleCode fails to finish.

Workflow PeopleCode programs typically review the data in the saved record, then

decide which business event to trigger, if any. They all include at least one use of the

PeopleCode function that triggers events, or Virtual_Router, a PeopleCode library

function that is associated with Virtual Approver, which uses TriggerBusinessEvent

internally. The Virtual_Router PeopleCode library function is located in the

FieldFormula event of the APPR_VA0_WRK.FUNCLIB_02 record field.

You can add the Workflow PeopleCode to any field in the record definition. For

clarity, you can add it to a field that the program itself references. For example, you

might add the Workflow PeopleCode that triggers an approval process to the

Approval Status field.

Using the TriggerBusinessEvent Function:

You use this function in every Workflow PeopleCode program.

In components that use Virtual Approver, you don’t use these functions explicitly in

the Workflow PeopleCode. You use the Virtual_Router PeopleCode library function,

which uses these two functions internally.

TriggerBusinessEvent triggers a specified business event and the workflow routings

that are associated with that event. This is the syntax:

TriggerBusinessEvent(BUSPROCESS.BusProcName, BUSACTIVITY.ActivityName,

BUSEVENT.BusEventName)

The BusProcName, ActivityName, and BusEventName parameters are the names of

the business process, activity, and event from PeopleSoft Application Designer. They

are all strings, enclosed in quotes. For example, the following code triggers the Deny

Purchase Request event in the Manager Approval activity of the Purchase Requisition

business process:

TriggerBusinessEvent(BUSPROCESS."Purchase Requisition", BUSACTIVITY."Manager

Approval", BUSEVENT."Deny Purchase Request")

Page 45 of 90


Creating Workflow PeopleCode Programs:

Do not use this section for components with Virtual Approver.

The general structure of all Workflow PeopleCode programs is the same:

• Check for the condition under which a business event should be triggered.

This condition is a business rule.

• If the condition is true, trigger the event.

The system automatically determines whether the event is active, and if so,

triggers it. If you’ve deactivated the event, the system doesn’t run it.

This is a typical Workflow PeopleCode program:

/* Start the Employee Training process for a new course request */

if RecordNew(ATTENDANCE) then

if COURSE_TBL.INTERNAL_EXTERNAL = "I" then

/* For internal courses */

&TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training",

BUSACTIVITY."Request Course",

BUSEVENT."Internal Course Request");

else /* For external courses */

&TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training",

BUSACTIVITY."Request Course",

BUSEVENT."External Course Request");

end-if;

Page 46 of 90


Writing PeopleCode for Approval Processes:

This section provides an overview of approval processes and discusses how to:

• Use virtual approver.

• Use the GetApprovers library function

Approval processes are a common form of business process. PeopleSoft has

simplified the process of defining approval processes by enabling you to define

approval rules on an approval rule setmap. You can then choose a tool to read and

implement the approval rules from the map.

Using Virtual Approver:

As users complete transactions that require approvals, Virtual Approver

determines the appropriate approver and sends a workflow routing. As each

approver completes the approval, Virtual Approver determines whether

additional approvals are needed and, if necessary, sends additional workflow

routings.

Using the GetApprovers Library Function:

The GetApprovers function isn't a regular PeopleCode function. It's a library function,

like Virtual Approver. It's located in the FieldFormula event of the

APPR_VA0_WRK.APPR_RULE_SET record field.

The GetApprovers PeopleCode function checks an approval rules set and determines

the entire list of required approvals at once, so that you can develop custom

approval tracking applications.

Page 47 of 90


1.8 Using Batch Workflow Processing

This chapter provides overviews of workflow batch processes, batch workflow

applications, Database Agents conversion, and the Notification Class, and discusses

how to create batch workflow applications.

When you’re working with PeopleSoft applications, you perform some activities

interactively (online processes) and the system performs some behind the scenes

(batch processes). Batch processes provide three major benefits:

• You can schedule them to run later, on a recurring schedule.

• They can process a large number of items all together, unlike online

processes, which typically process one item at a time.

• You can transfer processing to a server so that time-consuming tasks don’t

monopolize your machine.

However, batch processes have one drawback: they connect to the database

directly, rather than working through the PeopleSoft pages. If your application

validates incoming data or runs custom PeopleCode, you might not want a batch

process updating the database in this way. Also, because you trigger business events

by saving data on a page, batch processes can’t initiate a workflow.

Batch Workflow Processing

Sometimes, the event that triggers a workflow routing is actually a nonevent. That

is, a situation exists, but not because someone has entered data into the system.

The most common examples of this type of event are aging processes. For example,

an invoice becomes overdue, an employee reaches his five-year anniversary, or a

worklist entry remains unworked for over a week.

PeopleSoft Application Engine enables you to monitor your database for this type of

event. You can create an Application Engine program that runs a SQL query against

the PeopleSoft database and passes the results to a component interface.

Page 48 of 90


Using Application Engine programs in conjunction with PeopleSoft Process Scheduler,

you can monitor the database tables for conditions that should trigger workflow

events.

Approval Processes

Approval processes are a very common form of business process, and you can define

approval rules on an Approval Rule Set map. The approval steps that you place on

this map represent the approval levels required for the activity in question.

Two tools can read and implement the approval rules from the map:

• Virtual Approver automatically tracks the approval process. As users complete

transactions that require approvals, Virtual Approver determines the

appropriate approver and sends a workflow routing. As each approver

completes the approval, Virtual Approver determines whether additional

approvals are needed and, if necessary, sends additional workflow routings.

• GetApprovers PeopleCode determines the entire list of required approvals at

once, so that you can develop custom approval tracking applications.

Activity Guides

Activity guides support a specific type of workflow: a single user’s work across

several pages. Because activity guides are intended for a single user, they do not

involve routings like those found in a regular workflow application. Rather, the

activity guide leads a user through a multistep task.

An activity guide appears as a navigation bar across the top of a page. Within the

bar, you can see each of the steps involved in the activity. Clicking a step takes you

to the page where you can complete the step; the navigation bar remains visible as

you move from page to page.

Activity guides take a single map and integrate it into the pages that are used for the

specific transaction. Although activity guides can benefit all users, they are

particularly appropriate for guiding untrained users through self-service transactions.

Of the two kinds of workflow maps (business processes and activities), only activities

are used for activity guides. The activity guide maps are built with the same tools as

all other maps.

Page 49 of 90


Notification Features

Within an activity definition, an event can trigger a notification routing in email or a

worklist. These features facilitate sending notifications in workflow:

• The Notify toolbar button can be added to any PeopleSoft component.

With the Notify toolbar button, the user can determine when an event has

occurred that requires that someone be notified. The Notify toolbar button

opens the Send Notification page, where the user can enter a personal

message and send an email or worklist notification to users.

• Notification templates enable functional users to configure unique message

text for each component.

The notification template can include values from the component page (for

example, order number and customer name) so that even the predefined text

in the notification can be specific to the data on the page. These values are

called template variables.

• The BlackBerry Email Response notification setup and polling program enables

companies to leverage the functionality of the Research in Motion (RIM)

wireless handheld device to send and receive email.

The email response from the device can trigger business logic in the

PeopleSoft system to update or complete a transaction.

The combination of generic templates and PeopleCode application classes can be

used by application developers to extend the delivered notification features for an

application.

Page 50 of 90


Activity 1.1 – Create a worklist workflow

In this activity, students will revisit the book lending application that was created

with application designer class and which was further enhanced in PeopleCode class.

We now need to add some workflow capabilities. Whenever the page is saved, a

worklist item must be generated everytime a book is borrowed or returned.

Page 51 of 90


2.1 PeopleSoft Security

PeopleSoft software provides security features, including components and

PeopleTools applications, to ensure that your sensitive application data does not fall

into the wrong hands. Most likely, you use other security tools for your network and

relational database management system (RDBMS). These tools work together to

protect the PeopleSoft system from unauthorized access.

The PeopleSoft security approach is tailored for the internet. It enables you to easily

create and maintain security definitions, and you can perform many maintenance

tasks programmatically.

You can apply security to all users, including employees, managers, customers,

contractors, and suppliers. You group your users according to roles to give them

different degrees of access. For instance, there might be an Employee role, a

Manager role, and an Administrator role. Users who belong to a particular role

require a specific set of permissions, or authorizations, within your system, so that

they can complete their daily tasks.

You must also secure the objects and definitions in your PeopleSoft development

environment. Just as you restrict sets of end users from accessing particular pages

and components, you also restrict the definitions that your site’s developers can

access using PeopleSoft Application Designer. A definition refers to any of the

definitions that you create within PeopleSoft Application Designer, such as records,

pages, or components. Each object definition may have individual security needs. For

example, you may have a large development staff, but perhaps you want only a few

developers to have access to specific record definitions.

PeopleSoft Security Definitions

Because deploying your applications to the internet significantly increases the

number of potential users your system must accommodate, you need an efficient

method of granting authorization to different user types. PeopleSoft security

definitions provide a modular means to apply security attributes in a scalable

manner.

Page 52 of 90


A security definition refers to a collection of related security attributes that you

create using PeopleTools Security. The three main PeopleSoft security definition

types are:

• User profiles.

• Roles.

• Permission lists.

User Profiles

User profiles define individual PeopleSoft users.

Each user has an individual user profile, which in turn is linked to one or more roles.

You add one or more permission lists, which ultimately control what a user can and

can't access, to each role. A few permission types are assigned directly to the user

profile.

Typically, a user profile must be linked to at least one role in order to be a valid

profile. The majority of values that make up a user profile are inherited from the

linked roles.

Roles

Roles are intermediate objects that link user profiles to permission lists. You can

assign multiple roles to a user profile, and you can assign multiple permission lists to

a role. Some examples of roles might be Employee, Manager, Customer, Vendor, and

Student.

A manager is also an employee, and may also be a student. Roles enable you to mix

and match access appropriately.

You have two options when assigning roles: assign roles manually or assign them

dynamically. When assigning roles dynamically, you use PeopleCode, LDAP, and

PeopleSoft Query rules to assign user profiles to roles programmatically.

Permission Lists

Permission lists are groups of authorizations that you assign to roles. Permission lists

store sign-in times, page access, PeopleTools access, and so on.

Page 53 of 90


A permission list may contain one or more types of permissions. The fewer types of

permissions in a permission list, the more modular and scalable your

implementation.

A user profile inherits most of its permissions through roles, but you apply some

permission lists, such as process profile or row-level security (data permissions),

directly to a user profile.

PeopleSoft Online Security:

The PeopleSoft system has many elements, such as batch processes, object

definitions, and application data. Use PeopleTools security tools to control access to

most of these elements. To secure other elements, you use application-specific

interfaces, such as Administer Security.


• Sign-in and time-out security.

• Page and dialog box security.

• Batch environment security.

• Definition security.

• Application data security.

• PeopleSoft Internet Architecture security.

Sign-in and Time-out Security

When a user attempts to sign in to PeopleSoft, he or she enters a user ID and a

password on the PeopleSoft Signon page. If the ID and password are valid,

PeopleSoft connects the user to the application, and the system retrieves the

appropriate user profile.

If the user attempts to sign in during an invalid sign-in time as defined in the user's

security profile, he or she is not allowed to sign in. A sign-in time is an adjustable

interval during which a user is allowed to sign in to PeopleSoft. If a user is signed in

when the sign-in period expires, PeopleSoft signs the user out automatically.

Page 54 of 90


A timeout interval specifies how long the user’s machine can remain idle—no

keystrokes, no SQL—before the PeopleSoft system automatically signs the user out

of the application.

You specify both the sign-in times and time-out interval using PeopleTools Security.

Page and Dialog Box Security

You can restrict access to PeopleSoft menus. You can set the access rights to the

entire menu, such as Administer Workforce or PeopleTools Security, or just a specific

item on that menu. Because the only normal way to access a PeopleSoft page is

through a menu, if a user has no access to a particular menu or menu item, then you

have effectively restricted that user's access to the corresponding page.

You can also restrict access to specific actions or commands on a page. For example,

you may want a clerk in your sales office to be able to access contract data, but not

be able to update the data. In this case, you grant access to the set of pages, but

you allow display only access only. In this case, the clerk cannot update or correct

any data. This approach enables users to get their work done while maintaining the

security and integrity of your business data.

Batch Environment Security

If a particular user must run batch processes using PeopleSoft Process Scheduler,

assign the appropriate process profile to the user profile and create process groups

for your processes. A user receives both process group and process profile

authorizations through permission lists. A user gets permission to process groups

through roles, and they get a process profile through the process profile permission

list.

Process Security

Because PeopleSoft applications take advantage of other applications, such as SQR

and COBOL, your batch processes should be run in in a secure environment.

There are three levels of security for batch programs:

• Each batch program has a run control that you define before you can run the

batch program.

Page 55 of 90


Run controls are set up using PeopleSoft Process Scheduler

• PeopleSoft Process Scheduler enables you to set up process groups, which are

groups of batch processes.

In PeopleTools Security you add process groups to a security profile. Users

can run processes that belong to the process groups assigned to their security

profile.

• In your RDBMS environment, you can restrict offline access to batch

processes using the security tools described in your platform manuals.

Reporting Security

PeopleSoft Report Manager uses a logical space on a web server called the Report

Repository. PeopleSoft Report Manager enables you to generate and distribute

reports over the internet, and it stores the output in the Report Repository.

Wherever you decide to situate your repository, make sure that the server is

protected from outside access. Ensure that only the PeopleSoft system can access

and distribute the generated reports. The Report Repository servlet gets items from

the web server and puts them in the browser. With report distribution, you distribute

reports and view them according to your role.

PeopleSoft delivers these roles for the specific use in reporting:

• ReportDistAdmin

• ReportSuperUser

Definition Security

Use Definition Security to govern access to database object definitions, such as

record definitions, field definitions, and page definitions, and to protect particular

object definitions from being modified by certain developers.

Application Data Security

Definition security is a form of data security—you use it to control access to

particular rows of data (object definitions) in PeopleTools tables. PeopleSoft software

also provides other methods to control the application data that a user is allowed to

access in the PeopleSoft system. This task is also known as setting data permissions.

Page 56 of 90


With application data security, you can set data permissions at the following levels:

• Table level (for queries only).

• Row level.

• Field level.

Table-Level Security

You use PeopleSoft Query to build SQL queries and retrieve information from

application tables. For each PeopleSoft Query user, you can specify the records the

user is allowed to access when building and running queries. You do this by creating

query access groups in PeopleSoft Tree Manager, and then assigning users to those

groups with PeopleSoft Query security. PeopleSoft Query security is enforced only

when using PeopleSoft Query; it doesn’t control runtime page access to table data.

Row-Level Security

You can design special types of SQL views—security views—to control access to

individual rows of data stored within application database tables. Row-level security

enables you to specify the data that a particular user is permitted to access.

PeopleSoft applications are delivered with built-in row-level security functions that

are tailored to specific applications.

For example, PeopleSoft Human Resources security tables enable you to restrict user

access to employee rows of data according to organizational roles. You could also

permit users to view and update rows for employees in their departments only.

Similarly, in PeopleSoft Financials, you can use security views to determine access to

business units and ledgers. You can also use security tables to grant privileges by

access group to users who use PeopleSoft Query to access data from the database.

See the documentation for your application for details about implementing row-level

security for your applications.

Field Security

Use PeopleCode to restrict access to particular fields or columns within application

tables. For example, if you want a certain class of user to be able to access certain

pages, but not to view a particular field on those pages, such as compensation rate,

you can write PeopleCode to hide the field for that user class.

Page 57 of 90


PeopleSoft Internet Architecture Security

PeopleSoft Internet Architecture security is also known as runtime security. Only

authorized users can connect to the web and application server, and only authorized

application servers can connect to a given database.

PeopleSoft software uses authentication tokens embedded in browser cookies to

authorize users and enable single sign-in throughout the system. To secure links

between elements of the system, including browsers, web servers, application

servers, and database servers, PeopleSoft software incorporates a combination of

Secure Sockets Layer (SSL) security and BEA Tuxedo and BEA Jolt encryption.

Establishing an SSL connection requires two certificates: one containing the public

key of the server (server certificate or public key certificate) and another to verify

the certification authority that issued the server certificate (trusted root certificate).

The system uses BEA Tuxedo and BEA Jolt encryption in these locations:

• Between the web server and the application server.

• Between the integration gateway and a PeopleSoft system (BEA Jolt only).

Security between the application server and database is supplied by RDBMS

connectivity.

PeopleSoft Integration Broker and portal products have additional security concerns,

which are addressed in the documentation for those products.

PeopleSoft Authorization Ids:

The PeopleSoft system uses various authorization IDs and passwords to control user

access. You use PeopleTools Security to assign two of these IDs: the user ID and the

symbolic ID.

User Ids

PeopleSoft user ID is the ID you enter at the PeopleSoft sign-in dialog box. You

assign each PeopleSoft user a user ID and password. The combination of these two

Page 58 of 90


items grants users online access to the PeopleSoft system. The system can also use

a user ID stored within an LDAP directory server.

The user ID is the key used to identify the user profile definition.

Connect ID

The connect ID performs the initial connection to the database.

A connect ID is a valid user ID that, when used during sign-in, takes the place of

PeopleSoft user IDs. Using a connect ID means you don’t have to create a new

database user for every PeopleSoft user that you add to the system.

Warning! Without a connect ID specified, the system assumes that workstation is

accessing PeopleSoft through an application server. The option to override the

database type is disabled

Access Ids

When you create any user ID, you must assign it an access profile, which specifies

an access ID and password.

The PeopleSoft access ID is the RDBMS ID with which PeopleSoft applications are

ultimately connected to your database after the PeopleSoft system connects using

the connect ID and validates the user ID and password. An access ID typically has all

the RDBMS privileges necessary to access and manipulate data for an entire

PeopleSoft application. The access ID should have Select, Update, and Delete access.

Users do not know their corresponding access IDs. They just sign in with their user

IDs and passwords. Behind the scenes, the system signs them into the database

using the access ID.

If users try to access the database directly with a query tool using their user or

connect IDs, they have limited access. User and connect IDs only have access to the

few PeopleSoft tables used during sign-in, and that access is Select-level only.

Furthermore, PeopleSoft encrypts the sensitive data that resides in those tables.

Page 59 of 90


Symbolic Ids

PeopleSoft encrypts the access ID when it is stored in the PeopleTools security

tables. Consequently, an encrypted value can’t be readily referenced or accessed. So

when the access ID, which is stored in PSACCESSPRFL, must be retrieved or

referenced, the query selects the appropriate access ID by using the symbolic ID as

a search key.

The symbolic ID acts as an intermediary entity between the user ID and the access

ID. All the user IDs are associated with a symbolic ID, which in turn is associated

with an access ID. If you change the access ID, you need to update only the

reference of the access ID to the symbolic ID in the PSACCESSPRFL table. You do not

need to update every user profile in the PSOPRDEFN table.

PeopleSoft Sign-in:

The most common direct sign-in to the PeopleSoft database is the application server

sign-in.

These are the basic steps that are taken when the application server signs in to the

database:

1. Initial connection.

The application server starts, and uses the connect ID and user ID specified in

its configuration file (PSAPPSRV.CFG) to perform the initial connection to the

database.

2. The server performs a SQL Select statement on security tables.

After the connect ID is verified, the application server performs a Select

statement on PeopleTools security tables, such as PSOPRDEFN,

PSACCESSPRFL, and PSSTATUS. From these tables, the application server

gathers such items as the user ID and password, symbolic ID, access ID, and

access password. After the application server has the required information, it

disconnects.

3. The server reconnects with the access ID.

When the system verifies that the access ID is valid, the application server

begins the persistent connection to the database that all Pure Internet

Architecture and Windows three-tier clients use to access the database.

Page 60 of 90


Typically, the users signing in using a Microsoft Windows workstation are

developers using PeopleSoft Application Designer or end users who need to

access PeopleSoft Query or Tree Manager.

PeopleSoft recommends that all connectivity be made through either a three-tier

Microsoft Windows client or through the browser. A two-tier connection is no longer

necessary other than for the application server, PeopleSoft Process Scheduler, or for

a user who will be running upgrades or PeopleSoft Data Mover scripts.

Sign-in PeopleCode does not run during a two-tier connection, so maintaining two-

tier users in an LDAP server is not supported.

Directory Server Integration

PeopleSoft enables you to integrate your authentication scheme for the PeopleSoft

system with your existing infrastructure. You can reuse user profiles and roles that

are already defined within an LDAP directory service.

Organizations typically store user profiles in a central repository that serves user

information for all of the programs that require it. The central repository is typically

an LDAP directory server.

A directory server enables you to maintain a single, centralized user profile that you

can use across all of your PeopleSoft and non-PeopleSoft applications.

You always maintain permission lists and roles using PeopleTools Security. However,

you can maintain user profiles in PeopleTools Security or with an external LDAP

server.

Authentication and Signon PeopleCode

You can store PeopleSoft passwords within PeopleTools, in the PSOPRDEFN table.

You can also store and maintain user passwords and the rest of the user profile data

in an LDAP directory server. PeopleSoft retrieves the information stored in an

external directory server using a combination of the User Profiles component

interface and sign-in PeopleCode.

If you decide to reuse existing user profiles stored in a directory server, you don’t

need to perform dual maintenance on the two copies of the user data—one copy in

the LDAP server and one copy in PSOPRDEFN. PeopleSoft ensures that the user

Page 61 of 90


information stays synchronized. If you configure LDAP authentication, you maintain

your user profiles in LDAP and not in PeopleTools Security.

You can use signon PeopleCode and business interlinks to synchronize the local copy

of the user profile with any data source at sign-in time—the program that ships with

PeopleTools is designed to synchronize the user profile with an LDAP directory server

only. Because the sign-in program is PeopleCode, you can modify it, incorporating

any of the PeopleSoft integration technologies that PeopleCode supports.

To edit the signon PeopleCode program, you open the LDAP function library record

and use the PeopleCode editor to customize the PeopleCode. Developers who modify

the sign-in PeopleCode program need to have a good understanding of PeopleCode

and the integration features it offers.

Single Signon

Pure Internet Architecture uses browser cookies for seamless single signon across all

PeopleSoft nodes. A node refers to a database and the application servers connected

to it. For example, a user can complete a PeopleSoft Human Resources transaction,

and then click a link for a PeopleSoft Financials transaction without ever reentering a

password. Single signon is especially important to the PeopleSoft portal, which

aggregates content from several different applications and data sources into a single,

integrated display.

2.2 Security Administration

Security Administration Overview:


• User security.

• Lightweight Directory Access Protocol (LDAP).

• Authentication and single signon

• Query and definition security.

Page 62 of 90


User Security

User security is the core of security administration in PeopleSoft applications. You

administer user security using several basic elements.

To establish appropriate user access:

1. Define permission lists.

Permission lists are the building blocks of user security authorization. A

permission list grants a degree of access to a particular combination of

PeopleSoft elements, specifying pages, development environments, time

periods, administrative tools, personalizations, and so on.

This level of access should be appropriate to a narrowly defined and limited

set of tasks, which can apply to a variety of users with a variety of different

roles. These users might have overlapping, but not identical, access

requirements.

You typically define permission lists before you define roles and user profiles.

When defining permission lists, however, consider the roles that you will use

them with.

2. Define roles.

A role is a collection of permission lists. You can assign one or more

permission lists to a role. The resulting combination of permissions can apply

to all users who share those access requirements. However, the same group

of users might also have other access requirements that they don't share with

each other. You can assign a given permission list to multiple roles.

You typically define roles after first defining their permission lists, and before

defining user profiles. You use roles to assign permissions to users

dynamically.

3. Define user profiles.

A user profile is a definition that represents one PeopleSoft user. Each user is

unique; the user profile specifies a number of user attributes, including one or

more assigned roles. Each role that's assigned to a given user profile adds its

permission lists to the total that apply to that user.

Page 63 of 90


You typically define user profiles after defining their roles. You can assign a

given role to multiple user profiles. It's worthwhile to define a set of roles that

you're confident can be assigned to user profiles that you'll create in the

future.

Lightweight Directory Access Protocol (LDAP)

LDAP is an internet protocol used to access a directory listing. Organizations typically

store user profiles in a central repository, or directory server, that serves user

information for all of the programs that require it. If your existing computer network

uses an LDAP V3 compliant directory server, PeopleSoft supports the use of that

server for managing user profiles and authenticating users. PeopleSoft enables you

to integrate your authentication scheme for PeopleSoft with your existing

infrastructure.

You always maintain permission lists and roles using PeopleSoft security. However,

you can maintain user profiles in PeopleSoft security or reuse user profiles and roles

that are already defined within an LDAP directory server. A directory server enables

you to maintain a single, centralized user profile that you can use across all of your

PeopleSoft and non-PeopleSoft applications. This approach reduces redundant

maintenance of user information stored separately throughout your enterprise, and

reduces the possibility of user information getting out of synchronization.

You can configure and extend your signon PeopleCode to work with any schema

implemented in your directory server. You can assign roles to users manually or

assign them dynamically. When assigning roles dynamically, you use PeopleCode,

LDAP, and PeopleSoft Query rules to assign user profiles to roles programmatically.

Authentication and Single Signon

PeopleSoft delivers the most common authentication solutions and packages them

with your PeopleSoft application. This saves you the trouble of developing your own

solutions and saves you time with your security implementation. These prepackaged

solutions include PeopleCode that supports basic sign-in through secure sockets layer

(SSL), LDAP authentication, and single signon.

Because PeopleSoft applications are designed for internet deployment, many sites

must take advantage of the authentication services that exist at the web server

Page 64 of 90


level. PeopleSoft takes advantage of HTTPS, SSL, and digital certificates to secure

the transmission of data from the web server to an end user's web browser and also

to secure the transmission of data between PeopleSoft servers and third-party

servers (for business-to-business processing) over the internet.

PeopleSoft supports single signon within PeopleSoft applications. Within the context

of your PeopleSoft system, single signon means that after a user has been

authenticated by one PeopleSoft application server, that user can access a second

PeopleSoft application server without entering an ID or a password. Although the

user is actually accessing different applications and databases, the user navigates

seamlessly through the system. Recall that each suite of PeopleSoft applications,

such as HCM or CRM, resides in its own database.

Query and Definition Security

Security Administration Integrations:

This section identifies the Security integration points using:

• Component interfaces.

• Messages.

• Application Engine programs.

Component Interfaces:

The following are the delivered component interfaces designed for security

integration.

DELETE_ROLE

This component interface is based on the Delete Role (PURGE_ROLEDEFN)

component, and it is used to purge roles. It is keyed by RoleName, and has the Get,

Find, Save, Cancel methods. The DELETE_ROLE application message calls this

component interface.

DELETE_USER_PROFILE

This component interface is based on the Delete User Profile (PURGE_USR_PROFILE)

component, and it is used to purge User Profiles. It is keyed by User ID, and has the

Page 65 of 90


Get, Find, Save, Cancel methods. The Delete_User_Profile application message and

the PURGEOLDUSERS Application Engine program call this component interface.

ROLE_MAINT

This component interface is based on the Roles (ROLEMAINT) component. It is keyed

by RoleName and has the Cancel, Create, Find, and Get methods.

USERMAINT_SELF

This component interface is based on the My Profile (USERMAINT_SELF) component.

It allows only the current user to access it.

This CI is used with the following components: Forgot My Password (EMAIL_PSWD),

Change Password (CHANGE_PASSWORD), and Change Expired Password

(EXPIRE_CHANGE_PSWD).

USER_PROFILE

This component interface is based on the User Profiles (USERMAINT) component. It

is keyed by User ID.

This CI is used in User Profile Save As, and with LDAP authentication.

Messages:

The following are the delivered messages designed for security integration.

DELETE_ROLE

This message is called from the Delete Role component. It is used to the delete the

role from subscribing databases. The message requires that the DELETE_ROLE

component interface be authorized.

DELETE_USER_PROFILE

This message is called from the Delete User Profile component. It is used to delete

the user profile from subscribing databases. This message requires that the

DELETE_USER_PROFILE component interface be authorized.

Page 66 of 90


ROLESYNCH_MSG

This message is published when a Dynamic Role Rule is run. It is called after the

DYNROL_PUBL Application Engine program successfully finishes.

ROLE_MAINT

This Application Message publishes new Roles, and updates to existing Roles made in

the Roles component.

USER_PROFILE

This Application Message publishes new User Profiles and updates existing User

Profiles when using the User Profiles component (USERMAINT), the User Profile Save

As component, the My Profile component, the Distributed User Profile

(USERMAINT_DIST) component, the USER_PROFILE Component Interface and the

USERMAINT_SELF component interface.

Application Engine Programs:

PeopleSoft delivers Application Engine programs designed for security integration.

DYNROLE

The DYNROLE Application Engine program is called when Dynamic Role Rules are

published from the User Profile.

DYNROLE_PUBL

The DYNROLE_PUBL Application Engine program is called when the Dynamic Role

Rules are published from the Role.

PURGEOLDUSERS

The PURGEOLDUSERS Application Engine program deletes users that have not signed

on within a period specified on Password Controls.

LDAPSCHEMA

Application Engine Program that puts the LDAP Schema definition into the PeopleSoft

database.

Page 67 of 90


2.3 Setting Up Permission Lists

This chapter provides an overview of permission lists and discusses how to:

• Manage permission lists.

• Define permissions.

Permission lists are the building blocks of user security authorizations. You typically

create permission lists before you create user profiles and roles. When defining

permission lists, however, consider the roles and user profiles with which you will use

them. Recall that roles are intermediary objects between permission lists and users.

You use roles to assign permissions to users dynamically.

Permission lists may contain any number of permissions, such as sign-in times, page

permissions, and component interface permissions. Permission lists are more flexible

and scalable when they contain fewer permissions.

The following diagram illustrates how permission lists are assigned to roles, which

are then assigned to user profiles. A role may contain numerous permissions, and a

user profile may have numerous roles assigned to it. A user inherits all permissions

assigned to each role to which the user belongs. User access is determined by the

combination of all assigned roles.

Security definition hierarchy

Page 68 of 90


The diagram represents the security authorizations of Tom Sawyer. Mr. Sawyer

inherits the five permission lists that are assigned to the two roles that are assigned

to his user profile. In this example, he has access to the employee self-service

pages, the message monitor, PeopleSoft Process Monitor, and PeopleTools Security.

If Tom were to become a manager, then the permission lists assigned to the

Manager role would be added to his profile.

Theoretically, you could create a permission list tailored for every role, and that

permission list could contain a permission for every category, from General to Web

Libraries. However, permission lists like this do not scale to encompass roles that

might be similar, but not exactly alike. For a similar role, you'd have to create a new

role from the beginning. This kind of approach is not efficient for larger, more

complicated implementations.

Alternatively, you can use a more modular, or mix-and-match, approach where you

create numerous, generic permission lists that you can add to and remove from role

definitions. Suppose you have three 8-hour shifts at your site. Using the modular

approach, you could create three different versions of sign-in permissions: one for 6

a.m. to 2 p.m., one for 2 p.m. to 10 p.m., and another for 10 p.m. to 6 a.m. Then,

depending on the shift for a particular role, you can easily apply or remove the

appropriate permission as needed without affecting any other permissions.

Although how you decide to implement Permission Lists depends on your site's

security scheme and your security administrator, the modular approach provides

increased scalability. As a general rule, your permission lists should be assigned to

roles so that the common user has between 10 to 20 lists. This range represents the

best balance of performance and flexibility. If you have too many permission lists,

you may notice performance degradation, and if you have too few permission lists,

you may sacrifice flexibility.

Viewing Content References

Select PeopleTools, Security, Permissions & Roles, Permission Lists, Pages to access

the Pages page, then click the Edit Components link to access the Component

Permissions page.

Page 69 of 90


When you set component permissions and web library permissions, use the View

Content References link to view the content references pointing to a given

component or script. PeopleTools automatically propagates changes to permission

lists to the content references.

When you click the link, the Content References page appears, showing the

following:

• Name of the portal.

• Name of the content reference.

• The label.

• Whether or not it is accessible.

• The path.

Synchronizing Permission Lists and Content References

Use the PORTAL_CSS application engine program to synchronize permission lists

with content references for the portal. By default, the system synchronizes changes

in permission lists with content references; however, after an upgrade or any time

when you want to make sure, you can run the PORTAL_CSS program. There is a

process definition of the same name.

Adding Links

Select PeopleTools, Security, Permissions & Roles, Permission Lists, Links to access

the Links page.

Use this page to add links to other pages within your PeopleSoft system that pertain

to a particular permission list. For example, perhaps a PeopleSoft application

requires a specific security setting to be attached to a permission list. If this

application-specific setting appears on a page not in PeopleTools, Security, add a link

to that page so that anyone updating the permission list can easily navigate to it.

You create your inventory of links to security settings that exist outside of

PeopleTools Security using the Security Links page. After being created and assigned

Page 70 of 90


to a security definition, such as a permission list, then the links appear in the

security definition's list of links.

Running Permission List Queries

Select PeopleTools, Security, Permissions & Roles, Permission Lists, Permission List

Queries to access the Permission List Queries page.

Permission list queries enable you to run queries that provide detailed information

regarding a permission, such as the user IDs and roles associated with a permission

list. The available queries are documented on the page.

Page 71 of 90


Pages Used to Define Permission Lists

Setting General Permissions

Setting Page Permissions

Page permissions refer to the pages to which a user has access. Pages are contained

within components, which are ultimately contained within a menu name. To grant

access to a particular page, determine the component it is in and the menu name the

component falls under. This enables you to drill down to the appropriate page.

After you add a menu name, you grant access to its components and pages on an

item-by-item basis. In PeopleSoft applications, menu items represent components. If

Page 72 of 90


a component consists of more than one page, then selecting the menu item opens

another layer with more items—individual pages. For example, if you added the

UTILITIES menu name to a permission list, you could then grant access to the

Utilities, Use menu items but not to the Utilities, Process menu items. Or you could

grant access to only a few of the Use menu items, or make some items display only.

There are two categories of components to which you grant access permission:

• All PeopleSoft applications.

• Page-driven PeopleTools.

Granting Access to Components and Pages

The following procedure describes how to set access permissions to your PeopleSoft

applications and your page-driven PeopleTools. You begin at the component level

and drill down to the page level making the appropriate selections as you go.

To add access to PeopleSoft components and pages:

1. Locate the menu name of the component to which you want to add access.

2. Click Edit Components.

The Components page appears.

3. Locate the component to which you want to grant access.

By default, when adding a new permission list, no components are

authorized.

4. Click the Edit Pages button associated with each component to which you

want to grant access.

The Page Permissions page appears. You specify the actions that a user can

complete on the page. You have the following options for each page that

appears in the Page column:

• Authorized?

Select to enable a user to access the page. Decide the degree to which

a user is authorized on a page by selecting Display Only or one or

more of the available options in the Actions group.

Page 73 of 90


• Display Only.

Select to enable the user to view the information provided by the

page, but not to alter any data.

• Actions.

Specify how users can alter information on a page, such as Add,

Update/Display, and Correction. The available options depend upon

the options selected when the page was initially developed in

PeopleSoft Application Designer.

To grant access to all pages and all actions for each page, click Select

All.

5. When you have finished making the appropriate selections, click OK on the

Page Permissions page, and then again on the Component Permissions page.

Repeat each step for each menu name.

Setting PeopleTools Permissions

The PeopleTools Permissions section of this page applies to standalone PeopleTools

applications. They aren't Pure Internet Architecture-based, but are Microsoft

Windows programs that weren't developed using PeopleSoft Application Designer.

They include:

Page 74 of 90


• PeopleSoft Application Designer.

• PeopleSoft Data Mover.

• PeopleSoft Definition Security.

• PeopleSoft Query (Microsoft Windows interface, not the browser interface).

To grant access to these PeopleTools features, select the check box next to the

appropriate item.

With PeopleSoft Application Designer, the procedure for applying permissions is

slightly more complex, because security for PeopleSoft Application Designer also

controls what object definition types can be accessed and what degree of

modifications can be made. The links on this page (Definition Permissions, Tools

Permissions, and Miscellaneous Permissions) enable you to provide more detail to

PeopleSoft Application Designer access permissions.

Page 75 of 90


Definition Permissions

Select Definition Permissions to access the Object Permissions page.

Tools Permissions

In addition to object definitions, PeopleSoft Application Designer security also

involves a collection of tools, such as Build and the PeopleCode Debugger, to which

developers need access.

The tools within PeopleSoft Application Designer include the following:

• Build/Data Admin (select Build, Project and Tools, Data Administration).

• Change Control (select Tools, Change Control).

• Language Translations (select Tools, Translations).

• PeopleCode Debugger (select Debug, PeopleCode Debugger Mode).

• SQL Editor (the PeopleSoft Application Designer utility for adding SQL objects

and statements to applications and application engine programs).

• Upgrade (select Tools, Upgrade).

This includes Copy Project, Compare and Report, and so on.

Page 76 of 90


You can set the access level individually for the Tools Permissions page options or

your can use the (ALL) buttons to set across the board settings. Remember that

every button affects every access level for the tools.

Setting Component Interface Permissions

Setting Query Permissions

The Query page has links to the Permission List Access Groups page, where you can

define the records to which the user can have access in PeopleSoft Query, and the

Query Profile page, where you can define the query operations that the user can

perform.

Defining Access Groups

Click Access Group Permissions to access the Permission List Access Groups page.

Page 77 of 90


Access groups are nodes in a query tree, which you build with PeopleSoft Tree

Manager. After you’ve built a query tree, you give users access to one or more of its

access groups. Then they can generate queries on any tables in the access groups

accessible to them.

When you open Query Manager, it displays either an access group structure or an

alphabetical list of records to which you have access. Access groups enable you to

logically organize the record components to control security access within PeopleSoft

Query. It is not a physical representation of your database.

You can generate queries on and retrieve information only from the tables whose

record definitions are within these access groups. If, for example, you were querying

an order table and wanted to display data from a related table (like the customer

name rather than the customer code), you must have both tables—the order table

and the customer prompt table—in your access groups.

To create new queries, or even to run existing ones, users must have access rights

to the record components used in the queries. After you’ve built your query trees,

you must grant users access to them. You can grant and restrict access to entire

query trees or portions of them through the Access Groups page.

To add an access group to a permission list:

1. Open the permission list and select Query, Access Groups Permissions.

2. Select a tree name.

3. Select the highest access group that the user can access.

The system displays access groups in the selected query tree only.

The access group that you select should be the highest-level tree group to

which this permission list needs access. The Accessible check box is selected

by default. For example, users in the ALLPANLS permission list have access to

all record components in the EIS_ACCESS_GRP and all access groups below it

in the QUERY_TREE_EIS query tree—in other words, to all record components

in the tree.

4. (Optional) Clear the Accessible check box.

To grant access to most of the record components in a high-level access

group, but restrict access to one of the lower-level groups, you can add a new

Page 78 of 90


row for the lower-level access group and clear the Accessible check box.

Users can then access all record components within the higher-level group

except for those you explicitly made inaccessible.

5. Save your changes.

Defining Query Profiles

Access the Query Profile page

Query profiles specify available query operations. You can give users the right to run

queries but not create them, or to create regular queries but not workflow queries,

and you can restrict the SQL operations that users can perform. You control these

options through the query profile.

Each permission list has its own query profile, and the combination of all permission

lists that are assigned to a role determine the total query access for the role. User

profiles inherit query access only through the roles that you assign to them.

Page 79 of 90


2.4 Setting Up Roles

Roles are an intermediate object that exist between permission lists and user

profiles. Roles aggregate permission lists so that you can arrange permissions into

meaningful collections. If you implement dynamic roles, then you can add

permissions to users dynamically, which reduces administration tasks.

Role users are the user profiles or users that have membership in a particular role.

Users inherit most of their permissions from the roles assigned to the user profile.

However, you assign the following permission lists directly to a user profile:

• Data permissions.

These are assigned through a primary permissions list or a row security

permissions list.

• PeopleSoft Navigator homepage permissions.

• Process profile permissions.

When you assign roles to profiles manually, through the Security pages, these users

are called static role users.

Other users may obtain membership in a role programmatically. You can run a batch

process that runs 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.

Use dynamic role assignment to make your security system scale to large user

populations. If you have thousands of users and need to make every change to a

user profile manually, the security administrator becomes a bottleneck.

Page 80 of 90


2.5 Administering User Profiles

User profiles define individual PeopleSoft users. You define user profiles and then link

them to one or more roles. Typically, a user profile must be linked to at least one

role to be a usable profile. The majority of values that make up a user profile are

inherited from the linked roles.

You define user profiles by entering the appropriate values on the user profile pages.

The user profile contains values that are specific to a user, such as a user password,

an email address, an employee ID, and so on.

2.6 Implementing Query Security

This chapter discusses how to:

• Define query profiles.

• Build query access group trees.

• Work with query trees.

• Define row-level security and query security records

Defining Query Profiles

Query takes advantage of user's security settings, row-level security, and primary

permission list. Query is a PeopleTool that helps you build SQL queries to retrieve

information from your application tables. For each Query user, you can specify the

records they are allowed to access when building and running queries.

You do this by creating Query Access Groups in the Query Access Group Manager,

and then you assign users to those groups with Query permissions. Keep in mind

that Query permissions are enforced only when using Query; it doesn't control run-

time page access to table data.

Page 81 of 90


Building Query Access Group Trees

Trees are a graphical way of presenting hierarchical information. PeopleSoft Query

uses query access group trees to control the access of the tables in the PeopleSoft

database. You define a hierarchy of PeopleSoft record definitions, based on logical or

functional groupings, and then give users access to one or more nodes of the tree.

Users can retrieve information only from those tables whose record definitions to

which they have access.

You create and update query access group trees using Query Access Manager. To get

you started, we’ve included some sample query access group trees with the

PeopleSoft applications. Which trees you have depend on which PeopleSoft

applications you’ve installed. Each tree contains access groups and record definitions

categorized by function.

Access groups mark and define a functional group of records or other access groups

—in other words, they are descriptive placeholders used to categorize actual record

definitions in a logical, hierarchical format. When you define users’ security rights to

a tree, you specify which access groups they are permitted to query.

This section explains how to create query access group trees. It assumes that you’re

familiar with the concept and terminology of PeopleSoft trees.

Query Access Group Tree Considerations

You should create query access group trees based on your organization’s needs and

on any customizations you’ve made. Remember that the sample trees we provide

may be replaced when you upgrade to a subsequent PeopleSoft release, so if you

modify the samples rather than create your own trees, you may lose your

customizations.

Every record definition that you want users to be able to query must be in a query

tree. However, they don’t all have to be in the same query tree. One strategy is to

use the sample query trees to provide access to the standard PeopleSoft record

definitions, but create separate query trees for record definitions that you add in the

course of customizing the system. This way, you take advantage of the sample trees

but avoid overwriting your changes during future upgrades.

Page 82 of 90


How you organize the contents of the query tree depends on the needs of your

organization and your users. For example, you might want to create small trees that

are not intimidating to non-technical or casual users. The sample query trees

provided in the PeopleSoft application are divided by functions, but to simplify the

trees, you may want to create separate trees that contain subcategories of each

function. For example, you could create separate trees for U.S. and Canadian record

components to grant users in each region security access to only the record

components they should use.

Working with Query Trees

This section provides an overview of Query access group trees and discusses how to:

• Open Query access group trees.

• Define the Query tree.

• View and modify definitions.

Opening Query Access Group Trees

To open a Query tree definition:

1. Select PeopleTools, Security, Query Security, Query Access Manager.

2. On the Basic Search page select your search criteria.

You can search by Tree Name, Tree Category, Tree Description, Group Name

used in a Tree, or Record Name used in a Tree.

3. Click Search.

After clicking Search, a list appears containing the definitions that meet your

criteria.

4. Double-click the appropriate definition.

The list of trees in the lower part of the page also serves as a maintenance

utility enabling you to Delete or Copy a tree. If you click Delete, the system

Page 83 of 90


prompts you to confirm the action, and if you click Copy, the system displays

the Copy Tree page where you can select a name for the copied tree.

Defining the Query Tree

Before you can insert nodes for access groups and record components, you must first

define a number of important characteristics for the tree.

Access the Tree Definition and Properties page by selecting Create a New Tree on the

Basic Search Page

Viewing and Modifying Definitions

Page 84 of 90


Defining Row-Level Security and Query Security Records:

By default, when you give Query users access to a record definition, they have

access to all the rows of data in the table built using the associated record definition.

In some cases, though, you want to restrict users from seeing some of those data

rows. For example, you might not want your human resources staff to have access to

compensation data for vice presidents or above. In other words, you want to enforce

row-level security, which is offered by many PeopleSoft applications.

This section describes the relationship between row-level security and Query security

record definitions.

Row-Level Security

With row-level security, users can have access to a table without having access to all

rows on that table. This type of security is typically applied to tables that hold

sensitive data. For example, you might want users to be able to review personal data

for employees in their own department, but not for people in other departments. You

would give everyone access to the PERSONAL_DATA table, but would enforce row-

level security so that they could only see rows where the DEPTID matches their own.

PeopleSoft applications implement row-level security by using a SQL view that joins

the data table with an authorization table. When a user searches for data in the data

table, the system performs a related record join between the view and the base table

rather than searching the table directly. The view adds a security check to the

Page 85 of 90


search, based on the criteria you’ve set up for row-level security. For example, to

restrict users to seeing data from their own department, the view would select from

the underlying table just those rows where the DEPTID matches the user’s DEPTID.

Query Security Record Definitions

You implement row-level security by having Query search for data using a query

security record definition. The query security record definition adds a security check

to the search.

Query security record definitions serve the same purpose as search record definitions

do for panels. Just as a panel’s search record definition determines what data the

user can display in the panel, the query security record definition determines what

data the user can display with Query.

To get Query to retrieve data by joining a security record definition to the base table,

you specify the appropriate Query Security Record when you create the base table’s

record definition.

Each PeopleSoft product line comes with a set of views for implementing its standard

row-level security options. See the product documentation for details.

Typically, the Query Security Record definition you’ll want to select is the same one

you use as the search record definition for the panel that manages this table. If

you’re enforcing one of the standard row-level security options from a PeopleSoft

application, select the PeopleSoft-supplied security view for that option. See the

application documentation for a list of the available views. If you’ve designed your

own security scheme, select a record definition that appropriately restricts the rows a

query will return.

2.7 Definition Security

We will discuss

• Definition security.

• Definition groups and permission lists.

• Definition security rules.

Page 86 of 90


You can restrict developer access to the record definitions, menu definitions, page

definitions, and others that make up your applications. Just as you use Security to

control who can access the PeopleSoft pages in your system, you use Definition

Security to control who can access and update PeopleTools definitions.

There are two tasks involved with definition security:

• Creating definition groups.

• Linking definition groups to predefined permission lists.

Definition Security settings also works at the field level. To change a field on a

record, you must be authorized to update all record definitions that contain the field.

For example, to update or rename the EMPLID field on any record definition, you

must have access to every record definition that contains the EMPLID field. If you are

denied access to the ABSENCE_HIST record definition, which contains EMPLID, you

won’t be able to modify any field attributes of EMPLID on any other record that

contains the field. This ensures the integrity of your system. In a fast-paced

development environment, if PeopleTools definitions are not well secured, problems

may result.

Definition Groups and Permission Lists:

Use Definition Security to define definition groups and link them to permission lists

that you created in Security.

A definition group is a collection of one or more definitions that form a logical group

for security purposes. For example, you’ve created a permission list for analysts who

support the PeopleSoft Payroll module, and you call it PAYROLL_DEV. The analysts

are allowed to update only payroll definitions. Using Definition Security, you create a

definition group containing only payroll definitions, and give it a name, such as

PAYROLL_OBJ. Finally, you link PAYROLL_OBJ to PAYROLL_DEV.

You can assign multiple definition groups to a single permission list.

You can't declare directly that a particular permission list can modify a specific

definition type. You do so indirectly by creating a definition group that consists solely

of the desired definition type. Also, remember that you can assign a definition to

multiple groups as needed. To ensure total definition security, assign every definition

to at least one definition group.

Page 87 of 90


Activity 2.1 - NavigateNavigate through Peoplesoft HRMS security structure.

Activity 2.2 – Creation of permission list, role and user idCreate a Permission list and attach all the development done by trainees till

now to that Permission list. Create a role and assign it to the permission list

created above. Create a user profile and associate it to role. You can run a

role Query to associate the given role to user profile. Test user profile for

appropriate permissions by signing on again using the user ID created.

Activity 2.3 – Walkthrough on Department row level security Implementing Data Permissions by Using TreesIn this activity, you will review the activity overview and

Modify a department security tree.

Update data permission security.

Assign department access to a permission list

In this activity, you will modify a department security tree by creating a new

effectivedate tree for DEPT_SECURITY with setID SHARE. On the new tree,

you will add a new node and move a node. You will then run the batch

process to update the security tree. Once the update process has completed,

you will change the permission list HCDPUSA to use the new department and

test the new permission.

To modify a department security tree:

Sign in to the HCM database as PS.

1. Select Tree Manager, Tree Manager.

2. Enter DEPT_SECURITY in the tree name field.

3. Select the DEPT_SECURITY tree with SHARE as the setID and January 1,

1990 as the effective date.

4. Click Save As, and enter today’s date for the effective date

5. Click Save As.

Page 88 of 90


6. Click Close.

7. Select Tree Manager, Tree Manager.

8. Enter DEPT_SECURITY in the Tree Name field.

9. Select the DEPT_SECURITY tree with SHARE as the setID and today’s date as the

effective date.

10. Expand the ALL DEPTS folder.

11. Click 42000 – Corporate Headquarters.

12. Click the Insert Child Node icon to insert a new child node.

13. Enter 44000 as the tree node, and click Add.

14. On the Department Profile page, enter values.

15. Click OK.

16. Click on 63000 – Fire Department, and click the Cut button.

17. Click on 44000 – Northwest Division, and click the Paste as Sibling

button.

18. Click Save.

Results

Department 63000 now displays as a sibling of department 44000:

Department security tree after moving nodes

Page 89 of 90


Updating Data Permission Security

1. Select Set Up HRMS, Security, Department Security, Update Dept Security.

2. Select DeptSecurity for the run control.

3. Enter the following values:

Update Row Level Security -- Selected

As Of Date -- Today’s date (the date of the security tree that you

Created earlier)

4. Click Run.

5. On the Process Scheduler Request page, click OK.

6. Click the Process Monitor link to verify the process has run successfully

Assigning Department Access to a Permission List

1. Select Set Up HRMS, Security, Department Security, Setup Security Access, and

select the row security permission list HCDPUSA.

2. Delete the row with the setID SHARE and the department ID ADMIN.

3. Insert a new row, and enter the following values:

SetID SHARE

DeptID (department ID) 42000

Access Code Read/Write

4. Click the Save button.

5. Sign out and sign in using user ID and password HCRUSA.

6. Select Workforce Administration, Personal Information, Biographical, Update

Personal Information.

7. Enter K as the employee ID.

8. Click Search.

Only departments 42000 and 63000 appear. Department 44000 would also appear,

but no one is in that department.

Page 90 of 90

Documents

PeopleSoft Workflow and Securitydocshare01.docshare.tips/files/7664/76646018.pdf · PeopleSoft Workflow and Security PeopleSoft workflow tools enable the definition of necessary rules