book 6 workflow_security-1
TRANSCRIPT
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
PeopleSoft Workflow and Security
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 and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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.
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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 Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
• 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
PeopleSoft Workflow and Security
• 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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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.
Assigned
Current User
Send an email message to the user to whom the work item is
assigned, warning that the item is overdue.
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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.
This section discusses:
• 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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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 Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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:
This section discusses:
• User security.
• Lightweight Directory Access Protocol (LDAP).
• Authentication and single signon
• Query and definition security.
Page 62 of 90
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
• 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 Workflow and Security
• 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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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
PeopleSoft Workflow and Security
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