Book 6 Workflow - Security-1

PeopleSoft Workflow and Class Security
1 Day Course
[A comprehensive 2 day tour on the capabilities of the SQR language and its usage in PeopleSoft]
PeopleSoft Workflow and Security
Table of Contents
1.1 REVIEW AGENDA......................................................................................... 3 1.2 PEOPLESOFT WORKFLOW TECHNOLOGY OVERVIEW.............................................. 3 1.3 THE 8 STEPS OF WORKFLOW DEVELOPMENT. ..................................................... 8 1.4 BUILDING WORKFLOW MAPS ........................................................................ 10 1.5 DEFINING ROLES AND USERS......................................................................... 22 1.6 DEFINING WORKLIST RECORDS...................................................................... 25 1.7 DEFINING EVENT TRIGGERS.......................................................................... 44 1.8 USING BATCH WORKFLOW PROCESSING........................................................... 48 2.1 PEOPLESOFT SECURITY............................................................................... 52 2.2 SECURITY ADMINISTRATION.......................................................................... 62 2.3 SETTING UP PERMISSION LISTS...................................................................... 68 2.4 SETTING UP ROLES..................................................................................... 80 2.5 ADMINISTERING USER PROFILES..................................................................... 81 2.6 IMPLEMENTING QUERY SECURITY................................................................... 81 2.7 DEFINITION SECURITY................................................................................. 86
Page 2 of 90
1.1
Review Agenda
In this topic we will cover two areas Workflow workflow enables automation of flow of information Security to maintain and control access to system based on user class and usage profile.
1.2
PeopleSoft Workflow Technology Overview
Many of the daily tasks performed by system users are part of larger tasks that involve a number of steps and multiple people working together, often in a predefined sequence. The term Workflow refers to the larger process, involving several people, the activities required, and the routing of data between the participants. The most common workflow tools used are simply means of communication between parties involved in the process. These communications often happen in the form of telephone calls, transfer of physical (paper) files from one office to another, emails or hand-written notes. These workflow media are easily deployed and the tools mostly do not require any specific skills. However, these kinds of systems rely on every participant in the chain knowing the steps and players involved. If one participant has to be replaced with another person, this knowledge has to be transferred onto the replacement. This can become increasingly difficult in settings where the same person partakes in many workflow processes, or when unforeseen short-term replacement needs arise. If the system and procedures are not well documented, the likelihood of breaking the workflow chain is high. In addition, these manual systems have little to no control features. Often, a person is not expecting to receive a particular item for processing from their workflow predecessor. If the predecessor fails to complete their task in a timely fashion, it is likely that no mechanisms are in place to remind them of the outstanding items. Page 3 of 90
PeopleSoft workflow tools enable the definition of necessary rules and routings within the system. These components are then used to tie together the individual activities necessary to accomplish a complex task. With careful planning and configuration, this infrastructure will deliver the right information
1.3
UNDERSTANDING PEOPLESOFT WORKFLOW:
The 3Rs of Workflow The corner stones of Workflow process automation within the PeopleSoft Student Administration application are the 3Rs Rules, Roles, and Routing. These three components work together to ensure that the organizations 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 organizations business processes and formulate them using PeopleSoft Workflow tools. They determine the conditions to trigger a workflow process; these conditions are also referred to as Business Events. Workflow Rules also specify what activities are required to process data related to a given business process, and the sequence of these activities. Figure 1 shows an example for the visual representation of a Business Process. Often, these visual representations are referred to as Workflow Maps.
Page 4 of 90

Figure 1 Sample Business Process
The icons
represent activities in the overall business process. Arrows indicate
the flow of data and the sequence of activities involved. In this example, a two-level approval process is triggered by generating a refund either online or through a batch transaction. The Rules are comprised of the conditions under which data flow must be initiated (often this is the completion of the a predecessor activity), and the definition of the follow-up activity. Each activity can in turn consist of multiple steps, possibly linked by their own set of rules.
Figure 2 Sample Activity Figure 2 shows the Quick Admit Process as a sample activity to illustrate the composition of an activity as a collection of atomic steps. Steps are often tasks that can be performed using a particular component or page in a PeopleSoft system. Activities can also define a sequence of steps, Business Events, and Routing specifications, as can be seen in Figure 3.
Figure 3 Sample Activity including a Business Event and Worklist Routing
Page 5 of 90

In this example, the completion of step Refund Approval triggers a Business Event Send for Approval that performs the Routing of data to a Worklist. In essence, Workflow Rules determine the tasks to be completed and their sequence.
Roles The Who? Roles describe how people fit into the Workflow. A Role is a class of users who perform the same type of work, such as Undergraduate Recruiters or Cashiers. Business Rules typically specify what role needs to perform a particular activity. For example, a rule can say that the bursar must approve every student refund. Roles direct the work to types of people rather than to specific individuals. Identifying Roles instead of individual users makes workflow more flexible and less maintenance intensive. Associating Roles with users makes it easy to ensure that workflow users have the security privileges they need to access the pages where they complete their work. Roles remain stable, even as people change jobs. Roles utilize the existing PeopleSoft security infrastructure. As such, Role definitions used for Workflow can either make use of static User-to-Role relationships, or employ query to select one or more Role users at the time of Workflow execution.
Routings The How? At the heart of each Workflow definition is a set of Business Events and the Routings associated with them. Routings are instructions that tell the system to forward information to the next step in the business process. They are the systems means of moving data from one place to another, from one activity to the next. Routings specify information destination and formatting: worklist entries, email messages, or electronic forms. In essence: Routings bring the flow into workflow. When creating a routing, the type of routing, data recipients, and data to be sent are defined. The data is usually a subset of the data from the step that is triggering the routing. A mapping specifies how the data from the application page is packaged for delivery to the routing destination.
Page 6 of 90

As mentioned previously, three basic Routing types exist: Worklists A Worklist is a list of the items awaiting an activity by a specific user. Users select items from the list, and the system automatically displays the pages they need to process each item. Worklists are automatically created as items are routed to them. To define a worklist, a worklist record definition and the appropriate routings must be created. Email With email routings, email messages can be sent to recipients in response to business events. Messages can inform users that there is work to be done. It is common and appropriate to define two routings for the same event: one that adds an item to a users 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 products 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 twoway communication: The recipient of the form can make changes to it and send it back to the PeopleSoft application.
Page 7 of 90
1.3
The 8 steps of workflow development.
This section discusses the steps required to build a workflow. Step One: Designing a Workflow Application Designing a workflow application can include three main steps: 1. Analyze and document your business requirements. 2. Diagram the process flow. 3. Document the workflow object attributes for business processes, activities, steps, events, and email and worklist routings. In the planning phase of your implementation, take advantage of all PeopleSoft sources of information, including the installation guides, PeopleTools documentation, and the PeopleBooks that are specific to your applications. After clearly designing your workflow requirements, you can proceed to building the workflow. Step Two: Build Supporting Definitions If the applications required for your workflow do not already exist, build the definitions that you need for fields, records, pages, components, and menus. Step Three: Create Workflow Maps Create the workflow maps comprising the steps, activities, and business processes required for your workflow as determined in step one. Use PeopleSoft Application Designer to create graphical maps that represent your business process. At this stage, you create maps only for the processes that are involved in the underlying application; you add PeopleSoft Workflow-specific elements to the maps when you define events and routings. Step Four: Define Roles and Role Users
Page 8 of 90

Define the roles and the role users, including any Query roles, required for your workflow. To ensure that work flows to the correct person, you must determine who that person is. You can find the right person using either Query roles or user list roles. Step Five: Define Worklist Records Create a record definition that will be used to store all of the application-specific information for the worklist. The worklist record determines which fields of information the system stores for each work item, including the data needed to access the target page (the search keys for the page) and any additional information that you want to display in the worklist itself. Because different worklist entries can have different target pages and display data, you need separate worklist records for the different types of entries that will appear in the worklist. Step Six: Define the Workflow Objects This is the step in which you define the workflow application. You enter each of the objects onto a business process definition in Application Designer as determined in step one. You will define the events and routings that make up workflow. Events and routings are both objects on the workflow maps. To define these workflow objects, add the icons to the map, linked to the step representing the page where the triggering event occurs. Step Seven: Define Event Triggers Define the business rule in PeopleCode on the triggering application record definition. Workflow programs are defined on a record definition for one of the tables that the component accesses. They contain the business rules used to decide whether to trigger the business event. The PeopleCode detects when a business rule has been triggered and determines the appropriate action. Step Eight: Test Test your workflow, or use the workflow monitoring tools in Workflow Administrator to validate worklist routing results. Page 9 of 90

1.4 Building Workflow Maps
Workflow maps: also known as Navigator maps, are visual representations of your organization's business processes. Maps are necessary to all workflow processes, and they can also be used as navigational aids for end users. Workflow maps, also known as PeopleSoft Navigator maps, are visual
representations of your organization's business processes. Maps are necessary to all workflow processes, and they can also be used as navigational aids for users. There are two types of workflow maps, each representing a different hierarchical level. The top-level map, known as a business process, represents broad areas of functionality. Business processes contain one or more activities, or subprocesses. Activities contain individual steps that represent the specific transactions that complete that activity. PeopleSoft Navigator: is an alternative to the standard portal navigation. With PeopleSoft Navigator, users can see workflow maps and use them to access pages (but not external programs) that are represented within these maps. PeopleSoft Navigator presents maps according to their hierarchical relationships. Users can browse the available maps and navigate to individual pages by clicking the step that represents the page. As users move from map to page and back to map, the Navigator tree remains visible on the left-hand side of the screen:
Page 10 of 90

PeopleSoft Navigator You control which maps are visible in PeopleSoft Navigator by defining a Navigator homepage: a top-level business process that greets the user when PeopleSoft Navigator is first accessed. Users can access only the maps that are hierarchically related to this homepage. Map Hierarchies PeopleSoft Workflow uses three hierarchical levels. The first two levels, business processes and activities, are both maps: graphical representations of the relationships between the component objects (other maps or steps). The third level, steps, are not maps. Steps are elements within activities and represent the level at which the user interacts directly with application pages. Business processes and activities are both freestanding definitions that you can open in PeopleSoft Application Designer and include in projects. Because business processes include icons for other maps (activities or other business processes), create these lower-level maps before you add them to a business process. You can develop in a top-down approach by creating the lower-level maps from the Business Process Designer directly. Steps are not freestanding definitions in PeopleSoft Application Designer; they exist only within a particular activity. You create steps as you define an activity. Map Icons The following table presents the basic map elements.
The Business Process icon represents a complete business task, consisting of one or more activities. Business processes can include other business processes. Normally, you use this functionality only when designing maps for use in PeopleSoft Navigator. The Activity icon represents a subprocess of the business task, consisting of one or more steps. The Step icon represents a discrete step in the business process, corresponding to a single transaction performed on an application page or through an external program.
Business Processes Page 11 of 90

A business process is a graphical representation of the relationships between related activities. Arrows show the relationships between the activities, indicating the proper chronological sequence. Activities Activities that are intended only for end users (in PeopleSoft Navigator or in activity guides) typically include only steps that correspond either to application pages or to external programs. When you incorporate workflow, activities also include events and routings. Events represent specific transactions that can occur in the page that is connected to the event. Routings represent notifications that are triggered by that event. For example, there are several possible events on a page where managers approve orders. The manager can approve or deny the order or send the order back to the employee for changes. Each event requires routings to inform the next person in the chain (a buyer, an additional approver, or the employee who submitted the original order) about what must happen next. The following map shows an activity with workflow routings:
Activity with workflow routings
Defining Maps
Page 12 of 90

This section provides an overview of map definition, lists common elements, and discusses how to: Create a new map. Define business process properties. Define activity properties.
Creating a New Map To create a new map: 1. In PeopleSoft Application Designer, select File, New. 2. In the New scrolling list, select the map type: Activity or Business Process. 3. Click OK. 4. Add the icons required to represent the activity or business process. If youre creating a business process, the icons represent other maps, activities, and possibly other business processes. When you add these types of icons to the map, you can specify an existing activity or business process that the icon represents, or you are prompted to create a new one. Even if you do not save the business process on which you are working, the new activities or business processes that you created are saved to the database. Arrange the icons in a logical and visually informative way. If appropriate, add modeling symbols, drawings, arrows, text, or other graphic elements to the map. These elements are useful primarily in maps that are visible in PeopleSoft Navigator. They do not affect workflow processing, nor are they visible in activity guides. 5. Connect the activities, decision points, and subprocesses in the appropriate order: a. Click the Link button. b. Click the two objects sequentially. An arrow appears, pointing from the first object to the second.
Page 13 of 90

The links between steps only clarify the flow of work. They do not directly determine the order of the steps, which you specify when you set the properties for individual icons in the maps. However, if you've enabled automatic sequencing in the activity properties, the default step order is based on the links. 6. Define the properties of the map. 7. Define the properties of the icons on the map. 8. Save the map. Defining Business Process Properties To define the properties of a business process: 1. Open the business process in PeopleSoft Application Designer. 2. Open the Business Process Properties dialog box: a. Right-click in the map (but not on an item in the map). b. Select Definition Properties. The General tab in the Business Process Properties dialog box appears. 3. Set the properties on the General tab. 4. Set the properties on the Use tab. A Navigator homepage is the high-level business process that a user sees immediately after accessing PeopleSoft Navigator. A user's homepage settings are established on the User Profile and Permission List pages. To make this business process available as a homepage, select the Can be used as a Navigator home page check box. 5. Click OK to accept the settings. 6. Save the business process. Defining Activity Properties To define the properties of an activity: 1. Open the activity in PeopleSoft Application Designer.
Page 14 of 90

2. Open the Activity Properties dialog box. a. Right-click in the map (but not on an item in the map). b. Select Definition Properties. The General tab in the Activity Properties dialog box appears. 3. Set the properties on the General tab. 4. Set the properties on the Use tab. The Use tab includes options for automatically sequencing steps and for enabling end-user-facing activity guides. After you add steps to an activity, arrange them into a logical sequence using connecting arrows, and assign each step a number. If you select Automatically sequence steps, the step numbers are automatically assigned when you save the activity. The step numbers are based on the order in which you connect the arrows. This is an efficient way to order the steps. Select Activity Guide if youre creating a map to use as the basis for an enduser-facing activity guide. 5. Click OK to accept the settings.
Adding Map Objects This section provides an overview of toolbar buttons and discusses how to: Add icons to maps. Connect icons within a map. Add images to maps. Arrange objects on maps. Set icon properties. Control text. Add drawing shapes to maps. Use other map display features. Page 15 of 90

Understanding Toolbar Buttons Use toolbar buttons to add icons and connecting lines to maps. Different toolbars (and therefore different map objects) are available for business processes and activities. Business Process Toolbar This toolbar provides the basic components of a business process, including activities and the lines that link them. This toolbar is visible only when a business process is the active window. Click the Link button to connect related activities or steps. This button is also in the Activity toolbar. You must use the link tool to connect objects on the map; do not use arrows or other drawn shapes. Click the Business Process button to add another business process. Click the Activity button to add an activity. Click the Decision button to add a decision point in a process. A Decision icon in a map is descriptive only; it has no workflow functionality. This button is also in the Activity toolbar. Activity Toolbar This toolbar provides the basic components of an activity, including steps, workflow events, and workflow routings. This toolbar is visible only when the active window displays an activity. Click the Link button to connect related activities or steps. This button is also in the Business Process toolbar. Click the Step button to add a PeopleSoft page. Click the Event button to add a business event. Click the Worklist button to add a worklist. Click the Email button to add email for workflow routing. Click the Batch button to create a descriptive icon for a background process. Click the Manual Process button to create a descriptive icon for a manual
Page 16 of 90

process. Click the Decision button to create a descriptive icon for a decision point in a process. This button is also in the Business Process toolbar. Click the Local Transaction button to create a descriptive icon representing an application message definition for a transaction that occurs in one database. Click the Transaction other DB (transaction other database) button to create a descriptive icon representing an application message definition for a transaction that sends a message to another database in the same enterprise. Click the Remote Transaction button to create a descriptive icon representing an application message definition for a transaction that sends a message to another database in another enterprise by crossing the firewall. Application message definitions are used in PeopleSoft Integration Broker transactions.. Events and Routings Icons These are actual workflow objects, representing transactions that trigger workflow (events) and the medium through which the trigger sends work to the recipient (routings). You normally add these objects to activities after completing the basic maps. The following graphic presents the events and routings icons:
Events and routings icons
Adding Icons to Maps To add an icon to a map: 1. Click the toolbar button representing the icon that you want to add. 2. Click the map where you want to place the icon. Page 17 of 90

In most cases, the icon is added to the map when you click. If you're adding an icon for an activity, business process, or transaction, however, the Select Definition dialog box appears. 3. In the Select Definition dialog box, select the specific activity, business process, or application message definition that the icon represents. 4. Click the Select button to finish placing the icon on the map. Connecting Icons Within a Map To connect icons within a map: 1. Click the Link button on the toolbar. You must use the link tool to connect icons; do not use arrows or other drawing objects. 2. Click the icon where the link starts. The icon must be a linkable definition. As you pass the cursor over different parts of the map, its appearance changes to indicate whether youre over a linkable definition: A plus sign indicates that you are not over a linkable definition. A plus sign within a circle indicates that you are over a linkable definition. 3. Click the icon where the link ends. This click completes the link, and an arrow from one object to the other appears. Even if you relocate objects on the map, the link stays connected to both objects. To cancel without completing the link, right-click. 4. (Optional) Modify the shape of the link. To create angles at the same time that you create the link, make one or more intermediate clicks where you want the line to bend. You can add multiple angles. However, you must always end the line with a linkable definition.
Page 18 of 90

Change the angle by clicking the connector line, selecting the angle anchor, and moving it. To create an angle in an existing link, select the link, press and hold the CTRL key, and click where you want to create an angle anchor. You can then move the anchor as described previously. Understanding Descriptive Icons Both business processes and activities can include descriptive icons. These icons typically do not have associated workflow processing; they are useful primarily if the map will be visible through PeopleSoft Navigator. Setting Properties for Descriptive Icons To set properties for descriptive icons: 1. Right-click the descriptive icon and select Item Properties. The Properties dialog box appears. Depending on the type of icon, the title bar reads Business Processes Definition, Activity Definition, or Description Symbol Definition. 2. Enter information in the dialog box. The text that you enter in the Name field identifies the icon and, by default, appears as the display text under that icon. To display different text under the icon, enter it in the Icon Descr text box. Include line breaks in the text by pressing the ENTER key. 3. Click OK to close the dialog box. Setting Properties for Step Icons Set properties for the steps in an activity to associate the step with the proper page or external program and to establish the correct sequence of steps within the activity. To set properties for step icons: 1. Right-click the step icon and select Item Properties. The Step Definition dialog box appears. Page 19 of 90

2. Enter descriptive information about the step. 3. Enter the step and path numbers to place this step into the activitys flow. The Step Number and Path Number boxes order the steps in this activity. When the user always completes the same steps in the same order, specify the order of the step in the Step Number box and leave the number 1 in the Path Number box. The first step is step 1; the second is step 2. When the user performs different tasks along the way, define multiple step paths. Start numbering the steps from step 1, staying on path 1 until you reach the first point at which a user has options. For each step that might come next, use the next consecutive step number, but a different path number, for each one. All of the steps should have the same step number sequence, but a different path number value. If a user-facing activity guide based on this map is available, you might want to make the more common path the default path. Select Default Step for the step that you want the activity guide to take when a user progresses through the activity. You can avoid the manual sequencing of steps if you use the automatic step sequencing options that are available in the property sheet for the activity. However, always review the sequence created by automatic numbering to verify that the sequence is correct. 4. (Optional) Click Activity Guide. This button is available only if you have marked this as an activity guide in the activity properties. The Step Internet Client Attributes dialog box appears. If this map is an activity that will be used in an activity guide, enter the necessary information in this dialog box.
Setting Step Attributes
Page 20 of 90

This section discusses how to set step attributes.
Use the Step Attributes dialog box to select the page or program that the system starts when a user selects this step and the action mode that is used to open the page. To set step attributes: 1. On the Step Definition dialog box, click the Attributes button. 2. Specify whether the user completes this step on a PeopleSoft page or from an external program. When you select Page or External Program, the appropriate section of the dialog box becomes available. If this is an activity guide and youve marked the activity guide option in the activity properties, you must select Page. 3. Provide directions for starting the page or external program. If a user performs the step by completing a PeopleSoft page, select the page from the list boxes in the Processing Page group box. In the Actiondrop-down list box, select the type of activity that the user must perform on the database: Add,, Update/Display, Update Display/All, or Page 21 of 90

Correction. When a user selects this step, the system displays the specified page in the specified action mode. If users perform the step using an external program, select the program name and its working directory from the External Program group box. The program name must be the name of the executable file, followed by command line parameters, if appropriate. When a user selects this step, the system starts the specified program. 4. Click OK in the Step Attributes dialog box. 5. Click OK to close the Step Definition dialog box.
1.5
Defining Roles and Users
This chapter provides an overview of roles and users and discusses how to: Define a role query. Maintain roles and role users.
You can define a role as a fixed list of individual role users or as a query that selects one or more role users at runtime. This section discusses: User list roles. Query roles. Route controls. Case study: the manager query role
Page 22 of 90

User List Roles: PeopleSoft delivers a set of default user-list roles corresponding to the levels within an organization, such as EMPLOYEE, MANAGER, and VICE PRESIDENT. These roles are intended primarily for use with route controls. Use the following criteria to determine how to define a role: It doesnt 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 doesnt 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 employees 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 employees manager.
Page 23 of 90

Because of the flexibility they bring to business processes, query roles are more common than user list roles. When you create a query role, you tell the system how to determine who fills the role at runtime. You dont 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 users 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 factorvendor ID, business unit, and departmentand specify a range of values for each buyer.
Page 24 of 90
1.6
Defining Worklist Records
This topic provides an overview of worklist records and discusses how to: Create worklist record definitions. Replicate worklists.
The Worklist: The worklist can include several different types of items at once. For example, a manager might have entries related to approving both employee course enrollments and orders for supplies. Although both types of entries appear in the managers worklist, the underlying data is different. The course enrollment entries might display information about the course name and start date, while the orders might have information about the descriptions and prices of ordered items. Worklist Records: Entries in worklists are stored in database tables. You define the structure content of these tables by creating worklist records. The worklist record determines which fields of information the system stores for each work item and in what order the work items appear. When a business event routes a work item to a worklist, it adds a row to the table. When a user finishes with a work item, the system marks the row as worked. The basic procedure for creating a worklist record definition is the same as for any record definition, but worklist record definitions have some special requirements. Worklist Record Definitions When you create a worklist record definition, you define what a work item in a worklist looks like. The system uses the worklist record definition to: Link each work item with the underlying workflow tracking information, which is stored in a workflow system record (PSWORKLIST).
Page 25 of 90

Display relevant information about each work item on the Worklist page so that users can select the item on which they want to work. Retrieve the record that is associated with the work item so that the user can work on it. System Fields The first fields in a worklist record definition must always be the following system fields. System Field BUSPROCNAME ACTIVITYNAME EVENTNAME WORKLISTNAME INSTANCEID TRANSACTIONID Description The business process that includes the work item. The activity that triggers the worklist routing. The business event that triggers the worklist routing. The worklist in which the work item is waiting. The system-assigned ID for the work item. The system-assigned transaction ID for the work item. When an event triggers multiple routings, each work item has the same transaction ID, but a different instance ID. The system uses these fields to link the items in the worklist with their tracking information, which is stored in the PeopleSoft-defined table PSWORKLIST. They must be defined as ascending key fields in the worklist record definition. Virtual Approver, a specialized type of workflow used for approval processes, requires one additional system field. If you are using Virtual Approver, you must also add the APPR_INSTANCE field as a non-key field in the worklist record definition. This field stores the ID assigned to the work item for Virtual Approver processing. Application Fields The next set of fields in a worklist record definition are those specific to the application that creates the worklist. The system uses these fields to retrieve the associated record from the database when the user selects a worklist entry and moves to the page where the work is done. Note that: Page 26 of 90

Because the system uses the values from these fields to search for the associated database record, you must include all of the key fields for the search record. Application field names cannot be the same as key words used in field mapping. All of the application fields appear in the users 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 Field WORLKIST_URL The text that links to the page where the user can work on the item. Appropriate values might include the key data for the record in which the 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 users 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. Display Description
Page 27 of 90

Creating Worklist Record Definitions: To create a worklist record definition: 1. In PeopleSoft Application Designer, add the required system fields to the record definition. Identify the required system fields as key fields with ascending sort order. 2. Add the key fields from the search record for the page that group users use to process the worklist entries. The worklist record must include the search record key fields so that the system can locate the record on which the user must work. 3. (Optional) If users work on work items using an external program, rather than a PeopleSoft page, add a character field named COMMAND_PARM. When you define a step in an activity, you can specify that an external program starts when a user selects it. If the activity assigned to this worklist starts with such an activity, you can pass command-line arguments to the external program from the worklist record. For example, if you map a filename to the COMMAND_PARM field, the system appends the file name to the external programs command line (as specified in the step definition). 4. Add fields to provide descriptive information in the users worklist. If you have a compelling reason, you can add other application fields instead. However, dont add other application fields if youve added the WORKLIST_DESCR field, because using WORKLIST_DESCR automatically stops the worklist from displaying the application fields. 5. Save the record definition using a name that ends with _WL. 6. Create a database table using the record definition that you saved in step 5.1.8: Adding Events and Routings: This chapter provides an overview of events and routings and discusses how to: Add and define events Add and define worklist routings.
Page 28 of 90

Events and Routings When you create a business process in PeopleSoft Application Designer, you specify which activities form a business process and in what order they must be completed. The map provides an overview of the process, but it doesnt provide a link between the activities. To link the activities to a workflow, you add routings, which automate the delivery of information to other activities and other users. Events are conditions that have associated routings. Define the condition in PeopleCode, which is attached to the record definition underlying a step in a step map. When a user saves the page, completing the step, the system runs the PeopleCode program to test the condition. If the condition is met, the system performs the routings. Routings can deliver data in two forms: worklist entries and email messages. To create a routing, specify the routing type, who should receive the data, and which data you want to send. The data is usually a subset of the data from the step that triggers the routing. Adding and Defining Events: Add and define events in PeopleSoft Application Designer. This section discusses how to: Add an event Define the event Edit the business rules
Adding an Event: To add an event: 1. Open the activity to which you want to add the event. 2. Click the Event button in the toolbar. 3. Click where you want the event to appear on the map. The Event icon appears on the map. 4. Connect the Event icon to the icon for the step that triggers it. a. Click the Connector icon in the palette. Page 29 of 90

b. Click the Step icon, then the Event icon. An arrow connects the two icons. Use the Link icon, not the Line icon, to connect an event to the step that triggers it. If you use the Line icon, the system wont 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 Record Name Select the record definition to which you want to add Workflow Triggered from PeopleCode to trigger the business event
Editing the Business Rules To edit the business rules: 1. Click the Edit Business Rules button. The PeopleCode Editor appears. The name of the first key field in the specified record definition appears in the title bar. 2. Enter the PeopleCode that triggers the business event. 3. Save the PeopleCode. 4. Click OK to close the Event Definition dialog box. Page 30 of 90

Adding and Defining Worklist Routings: This section discusses prerequisites to defining worklist routings and discusses how to: Create worklist routings. Define worklist attributes. Specify field mappings.
Before you create a worklist routing for an activity, create a worklist record definition. The worklist record determines what fields the system stores for each work item. Creating Worklist Routings: To create a worklist routing: 1. Create the business event that triggers the worklist routing. 2. Click the Worklist button on the toolbar. 3. Click where you want the Worklist icon to appear on the map. The Worklist icon appears. 4. Connect the worklist routing to the event that triggers it. a. Click the Connector icon in the palette. b. Click the Event icon, then the Worklist icon. An arrow connects the two icons. Use the Link icon to connect a routing to an event. If you use the Line icon, the system wont recognize the routing. 5. Double-click the Worklist icon, or right-click and select Item Properties. The Worklist Definition dialog box appears. 6. Enter a name and description for the worklist routing. Defining Worklist Attributes: Define worklist attributes on the Worklist Attributes dialog box
Page 31 of 90
To define worklist attributes: 1. On the Worklist Definition dialog box, click Attributes. The Worklist Attributes dialog box appears. 2. Select the worklist record, business process, and activity from the appropriate drop-down list boxes. Worklist Record Business Process Activity Enter the business process name that is associated with the worklist item. 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 Select the record definition to use for storing and displaying work items.

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 elses 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 Reassignable Enables users to reassign worklist items to other users. Specifies whether the system checks this worklist for overdue items.
4. Specify the timeout parameters (if timeout processing is active). Timeout Parameters Specifying a timeout condition is optional. If you want all work items to remain in this worklist until a user processes them, leave the controls in this group box blank, or clear the Timeout Process Active check box. Otherwise, specify how long to wait (days, hours, and minutes) for a user to process a work item. The system adds the three values together. If a work item sits in the worklist for longer than the specified amount of time, the system performs the action identified by the check box that you select. Email Assigned Current User Email Supervisor Send an email message to the users supervisor. The supervisor is assigned as the users supervising role user in the user profile, maintained through PeopleSoft Security. In PeopleSoft HRMS applications, the system uses the supervisor from the users PERSONAL_DATA record. Send Timeout Send a new worklist item to the currently assigned users timeout Page 33 of 90 Send an email message to the user to whom the work item is assigned, warning that the item is overdue.

Worklist worklist.
5. Specify what the user must do before the system considers a work item to be worked. Work items remain in a users worklist until they have been worked. User Specified A work item is marked as worked when the user explicitly identifies it as worked by selecting it on the Select Worklist page and clicking the Mark Worked button. This option is useful when the user must return to the same work item several times or wait for supporting information. If the worklist item is replicated from another database, the Mark Worked function is disabled in the target database. Saved A work item is marked as worked when the user saves work on the page that is assigned to the worklist. This option is appropriate for work items that the user can complete right away. Selected A work item is marked as worked as soon as the user selects it from the worklist. This option is appropriate for work items that notify the user of an event; just seeing the item is sufficient. Programmatic A work item is never marked worked directly by the user. It can be marked as worked only with PeopleCode. This setting enables you to provide additional logic to determine when a work item can be considered worked. 6. Click OK to close the Worklist Attributes dialog box and return to the Worklist Properties dialog box. Specifying Field Mappings: Specify field mappings on the Field Map dialog box.
Page 34 of 90
To specify field mappings: 1. Click the Field Mapping button. If the Field Mapping button is unavailable, you havent properly linked the routing to the event that triggers it. The Field Map dialog box appears. Use this dialog box to tell the system where to find the data to create a worklist entry. The Message Map group box lists the fields involved. Name Displays the user ID (OPERID) of the person who receives the worklist routing. It may also display the fields in the worklist record, which includes key data Page 35 of 90

for the page where the user performs the necessary work and the descriptive data that appears in the users worklistnormally 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 doesnt 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 To enter the value from a database field into the worklist field, select the 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
Field Value RecField option. The Record box lists the record definitions that should

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 youve mapped bind values for all of the variables, click OK to close the dialog box. 9. If you map the field to a record field, specify whether the system copies the assigned value directly into the worklist field or replaces the assigned value with a value from the translate table. Select the appropriate option from the Map Mode list box. This list box is available only if the selected field has associated translate table values. In most cases, leave the default value (Copy). For example, suppose the worklist record definition includes an Employment Status field, and you associate the field with the record field PERSONAL_DATA.STATUS. If the PERSONAL_DATA.STATUS field holds an Page 37 of 90

abbreviation that translates to a value in the translate table, you can tell the system to populate the worklist field with the abbreviation (Copy) or with the corresponding translate table value (Xlat-S for the short form or Xlat-L for the long form). 10. Click OK to add the field and its value to the routing dialog box. 11. Repeat steps 5 to 10 for each field that you want to add to the worklist routing. You must provide values for all of the key fields in the worklist record definition. 12. Close all of the dialog boxes by clicking OK in each one. Adding and Defining Email Routings: This section provides an overview of email routings and discusses how to: Create an email routing. Map fields.
With email routings, you can send email messages in response to business events. In some cases, you might want to define two routings for the same event: one that adds an item to someones worklist and one that sends an email message to tell that person about the new worklist item. You can send an email routing to anyone to whom you can send email messages through the mail system. PeopleSoft applications support email routings to any email software that supports the Simple Mail Transfer Protocol (SMTP) standards. Creating an Email Routing: To create an email routing: 1. Create the business event that triggers the email routing. 2. Click the Email button on the toolbar. 3. Click where you want the Email icon to appear on the map. The Email icon appears. 4. Connect the email routing to the event that triggers it.
Page 38 of 90

a. Click the Connector button in the palette. b. Click the Event icon, then the Email icon. An arrow connects the two icons. 5. Use the Link icon to connect a routing to an event. If you use the Line icon, the system wont recognize the routing. 6. Double-click the Email icon, or right-click and select Item Properties. The Email Definition dialog box appears. 7. Enter a name and description for the routing. By default, the routing name also appears as the display text under the icon on the map. 8. Select any settings to apply to the email message. The options in this dialog box correspond to the mailing options offered in most email software. If your email software does not support one or more of these options, the system ignores its setting. See See the documentation for your email software. 9. Click to return to the Email Definition dialog box.
Mapping Fields:
Page 39 of 90
To map fields: 1. Select Field Mapping. 2. The Field Map dialog box appears. Use this dialog box to tell the system where to find the data to create an email message. The Message Map group box lists the fields involved. Name Value Displays the fields. Indicates where the system finds the data to enter in the fields.
The fields that appear in this dialog box represent the two different types of data that are needed to create an email message: who and what. That is: Who receives the email message? The TO field holds the email address for this person. What is the content of the email message? This includes a SUBJECT line and any additional text that you add. You can also concatenate data into the message. When you first open the dialog box, the Name column displays the fields available for mapping. You must provide a value for the TO field. 3. Select the field into which you want to map a value. 4. Click the Change button, or to add a new field to the map, click Add.
Page 40 of 90

5. The Map Field dialog box appears. Use this dialog box to create the email message from the values provided by the step that triggers the routing. 6. Select the field into which you want to place routing data. If you select the field from the message map, its name appears in the Field list box. If the correct name doesnt appear, you can select a field from the list box or enter a new name. The following fields in an email routings 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 SENDER CC BCC SUBJECT (Optional) Indicates the email address to which the sender recommends sending replies. (Optional) Indicates the email address of the actual originator of the email if different from the address set in the FROM field. and (Optional) Indicates the names of other people to whom you want to send the message. Indicates the subject line that appears in the receivers email inbox. 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
NOTETEXT Indicates the body of the message. The message can have multiple

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 To enter the value from a record field into the email message, select the 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 users 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
Field Value RecField option. The Record box lists the record definitions that should
Page 42 of 90

Name option. When you click this button, a dialog box appears, enabling you to specify the value that each bind variable in the query should take. The Query Bind Variable column displays the bind variables for the role query. (If nothing appears in this column, you defined the query without specifying any bind variables.) The Record column lists the record definitions associated with the component that triggers this routing. The Field column displays the fields in the selected record definition. You can bind each variable with the value from a record field or with a constant: To bind a variable with the value from a record field, select the Field option, select the bind variable for which you want to provide a value, and select the record field that will contain the value. To bind a variable with a constant, select the Constant option, and enter the value into the text box. When youve 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 persons employment status in the email message, so you associate the NOTETEXT field with the record field PERSONAL_DATA.STATUS. If the PERSONAL_DATA. STATUS field holds an abbreviation that translates to a value in the translate table, you can tell the system to populate the field with the abbreviation (Copy) or with the corresponding translate table value (Xlat-S for the short form or Xlat-L for the long form). 2. Click OK to add the field and its value to the routing dialog box. 3. Repeat steps for each field that you want to add to the routing. Page 43 of 90

4. Close all of the dialog boxes by clicking OK in each one.
1.7
Defining Event Triggers
This chapter provides an overview of event triggers and discusses how to: Write Workflow PeopleCode. Write PeopleCode for approval processes. Use additional PeopleCode functions and variables.
As you define workflow processes, you identify the application pages that trigger business events. Then you must add PeopleCode programs to the pages so that they actually trigger the events. The PeopleCode detects when a business rule has been triggered and determines the appropriate action. This section provides an overview of Workflow PeopleCode and discusses how to: Use the TriggerBusinessEvent function. Create Workflow PeopleCode programs.
Workflow PeopleCode To trigger a business event from a page, you add a PeopleCode program to the workflow event in the record definition for one of the tables to which the page writes. For example, to trigger events from the Course Request page, add Workflow PeopleCode to the TRAINING record definition; TRAINING is the record definition with which the Course Request page fields are associated. If youre triggering business events from a page that includes scrolls, add the Workflow PeopleCode to the record definition at the appropriate scroll level. If, for example, you add it to the record definition that is associated with a level one scroll area, the PeopleCode runs once for each row at that level. A Workflow PeopleCode program can reference record fields from record definitions at the same scroll level or at a lower scroll level. These rules also apply to the SaveEdit PeopleCode for Virtual Approver.
Page 44 of 90

Workflow PeopleCode runs after the user saves the page group and before it updates the database with the saved data. More specifically, it runs after SavePreChange PeopleCode and before SavePostChange PeopleCode. Because SavePostChange PeopleCode runs after Workflow PeopleCode, it does not run if the Workflow PeopleCode fails to finish. Workflow PeopleCode programs typically review the data in the saved record, then decide which business event to trigger, if any. They all include at least one use of the PeopleCode function that triggers events, or Virtual_Router, a PeopleCode library function that is associated with Virtual Approver, which uses TriggerBusinessEvent internally. The Virtual_Router PeopleCode library function is located in the FieldFormula event of the APPR_VA0_WRK.FUNCLIB_02 record field. You can add the Workflow PeopleCode to any field in the record definition. For clarity, you can add it to a field that the program itself references. For example, you might add the Workflow PeopleCode that triggers an approval process to the Approval Status field. Using the TriggerBusinessEvent Function: You use this function in every Workflow PeopleCode program. In components that use Virtual Approver, you dont 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, 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") BUSACTIVITY.ActivityName,
Page 45 of 90

Creating Workflow PeopleCode Programs: Do not use this section for components with Virtual Approver. The general structure of all Workflow PeopleCode programs is the same: Check for the condition under which a business event should be triggered. This condition is a business rule. If the condition is true, trigger the event. The system automatically determines whether the event is active, and if so, triggers it. If youve deactivated the event, the system doesnt run it. This is a typical Workflow PeopleCode program: /* Start the Employee Training process for a new course request */ if RecordNew(ATTENDANCE) then if COURSE_TBL.INTERNAL_EXTERNAL = "I" then /* For internal courses */ &TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training", BUSACTIVITY."Request Course", BUSEVENT."Internal Course Request"); else /* For external courses */
&TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training", BUSACTIVITY."Request Course", BUSEVENT."External Course Request"); end-if;
Page 46 of 90

Writing PeopleCode for Approval Processes: This section provides an overview of approval processes and discusses how to: Use virtual approver. Use the GetApprovers library function
Approval processes are a common form of business process. PeopleSoft has simplified the process of defining approval processes by enabling you to define approval rules on an approval rule setmap. You can then choose a tool to read and implement the approval rules from the map. Using Virtual Approver: As users complete transactions that require approvals, Virtual Approver determines the appropriate approver and sends a workflow routing. As each approver completes the approval, Virtual Approver determines whether additional approvals are needed and, if necessary, sends additional workflow routings. Using the GetApprovers Library Function: The GetApprovers function isn't a regular PeopleCode function. It's a library function, like Virtual Approver. It's located in the FieldFormula event of the APPR_VA0_WRK.APPR_RULE_SET record field. The GetApprovers PeopleCode function checks an approval rules set and determines the entire list of required approvals at once, so that you can develop custom approval tracking applications.
Page 47 of 90
1.8
Using Batch Workflow Processing
This chapter provides overviews of workflow batch processes, batch workflow applications, Database Agents conversion, and the Notification Class, and discusses how to create batch workflow applications. When youre 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 dont 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 cant initiate a workflow. Batch Workflow Processing Sometimes, the event that triggers a workflow routing is actually a nonevent. That is, a situation exists, but not because someone has entered data into the system. The most common examples of this type of event are aging processes. For example, an invoice becomes overdue, an employee reaches his five-year anniversary, or a worklist entry remains unworked for over a week. PeopleSoft Application Engine enables you to monitor your database for this type of event. You can create an Application Engine program that runs a SQL query against the PeopleSoft database and passes the results to a component interface.
Page 48 of 90

Using Application Engine programs in conjunction with PeopleSoft Process Scheduler, you can monitor the database tables for conditions that should trigger workflow events. Approval Processes Approval processes are a very common form of business process, and you can define approval rules on an Approval Rule Set map. The approval steps that you place on this map represent the approval levels required for the activity in question. Two tools can read and implement the approval rules from the map: Virtual Approver automatically tracks the approval process. As users complete transactions that require approvals, Virtual Approver determines the appropriate approver and sends a workflow routing. As each approver completes the approval, Virtual Approver determines whether additional approvals are needed and, if necessary, sends additional workflow routings. GetApprovers PeopleCode determines the entire list of required approvals at once, so that you can develop custom approval tracking applications. Activity Guides Activity guides support a specific type of workflow: a single users work across several pages. Because activity guides are intended for a single user, they do not involve routings like those found in a regular workflow application. Rather, the activity guide leads a user through a multistep task. An activity guide appears as a navigation bar across the top of a page. Within the bar, you can see each of the steps involved in the activity. Clicking a step takes you to the page where you can complete the step; the navigation bar remains visible as you move from page to page. Activity guides take a single map and integrate it into the pages that are used for the specific transaction. Although activity guides can benefit all users, they are particularly appropriate for guiding untrained users through self-service transactions. Of the two kinds of workflow maps (business processes and activities), only activities are used for activity guides. The activity guide maps are built with the same tools as all other maps.
Page 49 of 90

Notification Features Within an activity definition, an event can trigger a notification routing in email or a worklist. These features facilitate sending notifications in workflow: The Notify toolbar button can be added to any PeopleSoft component. With the Notify toolbar button, the user can determine when an event has occurred that requires that someone be notified. The Notify toolbar button opens the Send Notification page, where the user can enter a personal message and send an email or worklist notification to users. Notification templates enable functional users to configure unique message text for each component. The notification template can include values from the component page (for example, order number and customer name) so that even the predefined text in the notification can be specific to the data on the page. These values are called template variables. The BlackBerry Email Response notification setup and polling program enables companies to leverage the functionality of the Research in Motion (RIM) wireless handheld device to send and receive email. The email response from the device can trigger business logic in the PeopleSoft system to update or complete a transaction. The combination of generic templates and PeopleCode application classes can be used by application developers to extend the delivered notification features for an application.
Page 50 of 90

Activity 1.1 Create a worklist workflow In this activity, students will revisit the book lending application that was created with application designer class and which was further enhanced in PeopleCode class. We now need to add some workflow capabilities. Whenever the page is saved, a worklist item must be generated everytime a book is borrowed or returned.
Page 51 of 90
2.1
PeopleSoft Security software provides security features, including components and
PeopleSoft
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 sites developers can access using PeopleSoft Application Designer. A definition refers to any of the definitions that you create within PeopleSoft Application Designer, such as records, pages, or components. Each object definition may have individual security needs. For example, you may have a large development staff, but perhaps you want only a few developers to have access to specific record definitions. PeopleSoft Security Definitions Because deploying your applications to the internet significantly increases the number of potential users your system must accommodate, you need an efficient method of granting authorization to different user types. PeopleSoft security definitions provide a modular means to apply security attributes in a scalable manner.
Page 52 of 90

A security definition refers to a collection of related security attributes that you create using PeopleTools Security. The three main PeopleSoft security definition types are: User profiles. Roles. Permission lists.
User Profiles User profiles define individual PeopleSoft users. Each user has an individual user profile, which in turn is linked to one or more roles. You add one or more permission lists, which ultimately control what a user can and can't access, to each role. A few permission types are assigned directly to the user profile. Typically, a user profile must be linked to at least one role in order to be a valid profile. The majority of values that make up a user profile are inherited from the linked roles. Roles Roles are intermediate objects that link user profiles to permission lists. You can assign multiple roles to a user profile, and you can assign multiple permission lists to a role. Some examples of roles might be Employee, Manager, Customer, Vendor, and Student. A manager is also an employee, and may also be a student. Roles enable you to mix and match access appropriately. You have two options when assigning roles: assign roles manually or assign them dynamically. When assigning roles dynamically, you use PeopleCode, LDAP, and PeopleSoft Query rules to assign user profiles to roles programmatically. Permission Lists Permission lists are groups of authorizations that you assign to roles. Permission lists store sign-in times, page access, PeopleTools access, and so on.
Page 53 of 90

A permission list may contain one or more types of permissions. The fewer types of permissions in a permission list, the more modular and scalable your implementation. A user profile inherits most of its permissions through roles, but you apply some permission lists, such as process profile or row-level security (data permissions), directly to a user profile.
PeopleSoft Online Security: The PeopleSoft system has many elements, such as batch processes, object definitions, and application data. Use PeopleTools security tools to control access to most of these elements. To secure other elements, you use application-specific interfaces, such as Administer Security. 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

A timeout interval specifies how long the users machine can remain idleno keystrokes, no SQLbefore the PeopleSoft system automatically signs the user out of the application. You specify both the sign-in times and time-out interval using PeopleTools Security.
Page and Dialog Box Security

You can restrict access to PeopleSoft menus. You can set the access rights to the entire menu, such as Administer Workforce or PeopleTools Security, or just a specific item on that menu. Because the only normal way to access a PeopleSoft page is through a menu, if a user has no access to a particular menu or menu item, then you have effectively restricted that user's access to the corresponding page. You can also restrict access to specific actions or commands on a page. For example, you may want a clerk in your sales office to be able to access contract data, but not be able to update the data. In this case, you grant access to the set of pages, but you allow display only access only. In this case, the clerk cannot update or correct any data. This approach enables users to get their work done while maintaining the security and integrity of your business data.
Batch Environment Security

If a particular user must run batch processes using PeopleSoft Process Scheduler, assign the appropriate process profile to the user profile and create process groups for your processes. A user receives both process group and process profile authorizations through permission lists. A user gets permission to process groups through roles, and they get a process profile through the process profile permission list. Process Security Because PeopleSoft applications take advantage of other applications, such as SQR and COBOL, your batch processes should be run in in a secure environment. There are three levels of security for batch programs: Each batch program has a run control that you define before you can run the batch program.
Page 55 of 90

Run controls are set up using PeopleSoft Process Scheduler PeopleSoft Process Scheduler enables you to set up process groups, which are groups of batch processes. In PeopleTools Security you add process groups to a security profile. Users can run processes that belong to the process groups assigned to their security profile. In your RDBMS environment, you can restrict offline access to batch processes using the security tools described in your platform manuals. Reporting Security PeopleSoft Report Manager uses a logical space on a web server called the Report Repository. PeopleSoft Report Manager enables you to generate and distribute reports over the internet, and it stores the output in the Report Repository. Wherever you decide to situate your repository, make sure that the server is protected from outside access. Ensure that only the PeopleSoft system can access and distribute the generated reports. The Report Repository servlet gets items from the web server and puts them in the browser. With report distribution, you distribute reports and view them according to your role. PeopleSoft delivers these roles for the specific use in reporting: ReportDistAdmin ReportSuperUser
Definition Security
Use Definition Security to govern access to database object definitions, such as record definitions, field definitions, and page definitions, and to protect particular object definitions from being modified by certain developers.
Application Data Security

Definition security is a form of data securityyou use it to control access to particular rows of data (object definitions) in PeopleTools tables. PeopleSoft software also provides other methods to control the application data that a user is allowed to access in the PeopleSoft system. This task is also known as setting data permissions. Page 56 of 90

With application data security, you can set data permissions at the following levels: Table level (for queries only). Row level. Field level.
Table-Level Security You use PeopleSoft Query to build SQL queries and retrieve information from application tables. For each PeopleSoft Query user, you can specify the records the user is allowed to access when building and running queries. You do this by creating query access groups in PeopleSoft Tree Manager, and then assigning users to those groups with PeopleSoft Query security. PeopleSoft Query security is enforced only when using PeopleSoft Query; it doesnt control runtime page access to table data. Row-Level Security You can design special types of SQL viewssecurity viewsto control access to individual rows of data stored within application database tables. Row-level security enables you to specify the data that a particular user is permitted to access. PeopleSoft applications are delivered with built-in row-level security functions that are tailored to specific applications. For example, PeopleSoft Human Resources security tables enable you to restrict user access to employee rows of data according to organizational roles. You could also permit users to view and update rows for employees in their departments only. Similarly, in PeopleSoft Financials, you can use security views to determine access to business units and ledgers. You can also use security tables to grant privileges by access group to users who use PeopleSoft Query to access data from the database. See the documentation for your application for details about implementing row-level security for your applications. Field Security Use PeopleCode to restrict access to particular fields or columns within application tables. For example, if you want a certain class of user to be able to access certain pages, but not to view a particular field on those pages, such as compensation rate, you can write PeopleCode to hide the field for that user class. Page 57 of 90
PeopleSoft Internet Architecture Security

PeopleSoft Internet Architecture security is also known as runtime security. Only authorized users can connect to the web and application server, and only authorized application servers can connect to a given database. PeopleSoft software uses authentication tokens embedded in browser cookies to authorize users and enable single sign-in throughout the system. To secure links between elements of the system, including browsers, web servers, application servers, and database servers, PeopleSoft software incorporates a combination of Secure Sockets Layer (SSL) security and BEA Tuxedo and BEA Jolt encryption. Establishing an SSL connection requires two certificates: one containing the public key of the server (server certificate or public key certificate) and another to verify the certification authority that issued the server certificate (trusted root certificate). The system uses BEA Tuxedo and BEA Jolt encryption in these locations: Between the web server and the application server. Between the integration gateway and a PeopleSoft system (BEA Jolt only).
Security between the application server and database is supplied by RDBMS connectivity. PeopleSoft Integration Broker and portal products have additional security concerns, which are addressed in the documentation for those products.
PeopleSoft Authorization Ids: The PeopleSoft system uses various authorization IDs and passwords to control user access. You use PeopleTools Security to assign two of these IDs: the user ID and the symbolic ID.
User Ids
PeopleSoft user ID is the ID you enter at the PeopleSoft sign-in dialog box. You assign each PeopleSoft user a user ID and password. The combination of these two
Page 58 of 90

items grants users online access to the PeopleSoft system. The system can also use a user ID stored within an LDAP directory server. The user ID is the key used to identify the user profile definition.
Connect ID
The connect ID performs the initial connection to the database. A connect ID is a valid user ID that, when used during sign-in, takes the place of PeopleSoft user IDs. Using a connect ID means you dont have to create a new database user for every PeopleSoft user that you add to the system. Warning! Without a connect ID specified, the system assumes that workstation is accessing PeopleSoft through an application server. The option to override the database type is disabled
Access Ids
When you create any user ID, you must assign it an access profile, which specifies an access ID and password. The PeopleSoft access ID is the RDBMS ID with which PeopleSoft applications are ultimately connected to your database after the PeopleSoft system connects using the connect ID and validates the user ID and password. An access ID typically has all the RDBMS privileges necessary to access and manipulate data for an entire PeopleSoft application. The access ID should have Select, Update, and Delete access. Users do not know their corresponding access IDs. They just sign in with their user IDs and passwords. Behind the scenes, the system signs them into the database using the access ID. If users try to access the database directly with a query tool using their user or connect IDs, they have limited access. User and connect IDs only have access to the few PeopleSoft tables used during sign-in, and that access is Select-level only. Furthermore, PeopleSoft encrypts the sensitive data that resides in those tables.
Page 59 of 90
Symbolic Ids
PeopleSoft encrypts the access ID when it is stored in the PeopleTools security tables. Consequently, an encrypted value cant be readily referenced or accessed. So when the access ID, which is stored in PSACCESSPRFL, must be retrieved or referenced, the query selects the appropriate access ID by using the symbolic ID as a search key. The symbolic ID acts as an intermediary entity between the user ID and the access ID. All the user IDs are associated with a symbolic ID, which in turn is associated with an access ID. If you change the access ID, you need to update only the reference of the access ID to the symbolic ID in the PSACCESSPRFL table. You do not need to update every user profile in the PSOPRDEFN table. PeopleSoft Sign-in: The most common direct sign-in to the PeopleSoft database is the application server sign-in. These are the basic steps that are taken when the application server signs in to the database: 1. Initial connection. The application server starts, and uses the connect ID and user ID specified in its configuration file (PSAPPSRV.CFG) to perform the initial connection to the database. 2. The server performs a SQL Select statement on security tables. After the connect ID is verified, the application server performs a Select statement on PeopleTools security tables, such as PSOPRDEFN, PSACCESSPRFL, and PSSTATUS. From these tables, the application server gathers such items as the user ID and password, symbolic ID, access ID, and access password. After the application server has the required information, it disconnects. 3. The server reconnects with the access ID. When the system verifies that the access ID is valid, the application server begins the persistent connection to the database that all Pure Internet Architecture and Windows three-tier clients use to access the database. Page 60 of 90

Typically, the users signing in using a Microsoft Windows workstation are developers using PeopleSoft Application Designer or end users who need to access PeopleSoft Query or Tree Manager. PeopleSoft recommends that all connectivity be made through either a three-tier Microsoft Windows client or through the browser. A two-tier connection is no longer necessary other than for the application server, PeopleSoft Process Scheduler, or for a user who will be running upgrades or PeopleSoft Data Mover scripts. Sign-in PeopleCode does not run during a two-tier connection, so maintaining twotier 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 dont need to perform dual maintenance on the two copies of the user dataone copy in the LDAP server and one copy in PSOPRDEFN. PeopleSoft ensures that the user Page 61 of 90

information stays synchronized. If you configure LDAP authentication, you maintain your user profiles in LDAP and not in PeopleTools Security. You can use signon PeopleCode and business interlinks to synchronize the local copy of the user profile with any data source at sign-in timethe 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

User Security User security is the core of security administration in PeopleSoft applications. You administer user security using several basic elements. To establish appropriate user access: 1. Define permission lists. Permission lists are the building blocks of user security authorization. A permission list grants a degree of access to a particular combination of PeopleSoft elements, specifying pages, development environments, time periods, administrative tools, personalizations, and so on. This level of access should be appropriate to a narrowly defined and limited set of tasks, which can apply to a variety of users with a variety of different roles. These users might have overlapping, but not identical, access requirements. You typically define permission lists before you define roles and user profiles. When defining permission lists, however, consider the roles that you will use them with. 2. Define roles. A role is a collection of permission lists. You can assign one or more permission lists to a role. The resulting combination of permissions can apply to all users who share those access requirements. However, the same group of users might also have other access requirements that they don't share with each other. You can assign a given permission list to multiple roles. You typically define roles after first defining their permission lists, and before defining user profiles. You use roles to assign permissions to users dynamically. 3. Define user profiles. A user profile is a definition that represents one PeopleSoft user. Each user is unique; the user profile specifies a number of user attributes, including one or more assigned roles. Each role that's assigned to a given user profile adds its permission lists to the total that apply to that user.
Page 63 of 90

You typically define user profiles after defining their roles. You can assign a given role to multiple user profiles. It's worthwhile to define a set of roles that you're confident can be assigned to user profiles that you'll create in the future.
Lightweight Directory Access Protocol (LDAP) LDAP is an internet protocol used to access a directory listing. Organizations typically store user profiles in a central repository, or directory server, that serves user information for all of the programs that require it. If your existing computer network uses an LDAP V3 compliant directory server, PeopleSoft supports the use of that server for managing user profiles and authenticating users. PeopleSoft enables you to integrate your authentication scheme for PeopleSoft with your existing infrastructure. You always maintain permission lists and roles using PeopleSoft security. However, you can maintain user profiles in PeopleSoft security or reuse user profiles and roles that are already defined within an LDAP directory server. A directory server enables you to maintain a single, centralized user profile that you can use across all of your PeopleSoft and non-PeopleSoft applications. This approach reduces redundant maintenance of user information stored separately throughout your enterprise, and reduces the possibility of user information getting out of synchronization. You can configure and extend your signon PeopleCode to work with any schema implemented in your directory server. You can assign roles to users manually or assign them dynamically. When assigning roles dynamically, you use PeopleCode, LDAP, and PeopleSoft Query rules to assign user profiles to roles programmatically. Authentication and Single Signon PeopleSoft delivers the most common authentication solutions and packages them with your PeopleSoft application. This saves you the trouble of developing your own solutions and saves you time with your security implementation. These prepackaged solutions include PeopleCode that supports basic sign-in through secure sockets layer (SSL), LDAP authentication, and single signon. Because PeopleSoft applications are designed for internet deployment, many sites must take advantage of the authentication services that exist at the web server Page 64 of 90

level. PeopleSoft takes advantage of HTTPS, SSL, and digital certificates to secure the transmission of data from the web server to an end user's web browser and also to secure the transmission of data between PeopleSoft servers and third-party servers (for business-to-business processing) over the internet. PeopleSoft supports single signon within PeopleSoft applications. Within the context of your PeopleSoft system, single signon means that after a user has been authenticated by one PeopleSoft application server, that user can access a second PeopleSoft application server without entering an ID or a password. Although the user is actually accessing different applications and databases, the user navigates seamlessly through the system. Recall that each suite of PeopleSoft applications, such as HCM or CRM, resides in its own database.
Query and Definition Security Security Administration Integrations: This section identifies the Security integration points using: Component interfaces. Messages. Application Engine programs.
Component Interfaces: The following are the delivered component interfaces designed for security integration. DELETE_ROLE This component interface is based on the Delete Role (PURGE_ROLEDEFN) component, and it is used to purge roles. It is keyed by RoleName, and has the Get, Find, Save, Cancel methods. The DELETE_ROLE application message calls this component interface. DELETE_USER_PROFILE This component interface is based on the Delete User Profile (PURGE_USR_PROFILE) component, and it is used to purge User Profiles. It is keyed by User ID, and has the Page 65 of 90

Get, Find, Save, Cancel methods. The Delete_User_Profile application message and the PURGEOLDUSERS Application Engine program call this component interface. ROLE_MAINT This component interface is based on the Roles (ROLEMAINT) component. It is keyed by RoleName and has the Cancel, Create, Find, and Get methods. USERMAINT_SELF This component interface is based on the My Profile (USERMAINT_SELF) component. It allows only the current user to access it. This CI is used with the following components: Forgot My Password (EMAIL_PSWD), Change Password (CHANGE_PASSWORD), and Change Expired Password (EXPIRE_CHANGE_PSWD). USER_PROFILE This component interface is based on the User Profiles (USERMAINT) component. It is keyed by User ID. This CI is used in User Profile Save As, and with LDAP authentication.
Messages: The following are the delivered messages designed for security integration. DELETE_ROLE This message is called from the Delete Role component. It is used to the delete the role from subscribing databases. The message requires that the DELETE_ROLE component interface be authorized. DELETE_USER_PROFILE This message is called from the Delete User Profile component. It is used to delete the user profile from subscribing databases. This message requires that the DELETE_USER_PROFILE component interface be authorized.
Page 66 of 90

ROLESYNCH_MSG This message is published when a Dynamic Role Rule is run. It is called after the DYNROL_PUBL Application Engine program successfully finishes. ROLE_MAINT This Application Message publishes new Roles, and updates to existing Roles made in the Roles component. USER_PROFILE This Application Message publishes new User Profiles and updates existing User Profiles when using the User Profiles component (USERMAINT), the User Profile Save As component, the My Profile component, the Distributed User Profile (USERMAINT_DIST) component, the USER_PROFILE Component Interface and the USERMAINT_SELF component interface. Application Engine Programs: PeopleSoft delivers Application Engine programs designed for security integration. DYNROLE The DYNROLE Application Engine program is called when Dynamic Role Rules are published from the User Profile. DYNROLE_PUBL The DYNROLE_PUBL Application Engine program is called when the Dynamic Role Rules are published from the Role. PURGEOLDUSERS The PURGEOLDUSERS Application Engine program deletes users that have not signed on within a period specified on Password Controls. LDAPSCHEMA Application Engine Program that puts the LDAP Schema definition into the PeopleSoft database.
Page 67 of 90

2.3 Setting Up Permission Lists
This chapter provides an overview of permission lists and discusses how to: Manage permission lists. Define permissions.
Permission lists are the building blocks of user security authorizations. You typically create permission lists before you create user profiles and roles. When defining permission lists, however, consider the roles and user profiles with which you will use them. Recall that roles are intermediary objects between permission lists and users. You use roles to assign permissions to users dynamically. Permission lists may contain any number of permissions, such as sign-in times, page permissions, and component interface permissions. Permission lists are more flexible and scalable when they contain fewer permissions. The following diagram illustrates how permission lists are assigned to roles, which are then assigned to user profiles. A role may contain numerous permissions, and a user profile may have numerous roles assigned to it. A user inherits all permissions assigned to each role to which the user belongs. User access is determined by the combination of all assigned roles.
Security definition hierarchy
Page 68 of 90

The diagram represents the security authorizations of Tom Sawyer. Mr. Sawyer inherits the five permission lists that are assigned to the two roles that are assigned to his user profile. In this example, he has access to the employee self-service pages, the message monitor, PeopleSoft Process Monitor, and PeopleTools Security. If Tom were to become a manager, then the permission lists assigned to the Manager role would be added to his profile. Theoretically, you could create a permission list tailored for every role, and that permission list could contain a permission for every category, from General to Web Libraries. However, permission lists like this do not scale to encompass roles that might be similar, but not exactly alike. For a similar role, you'd have to create a new role from the beginning. This kind of approach is not efficient for larger, more complicated implementations. Alternatively, you can use a more modular, or mix-and-match, approach where you create numerous, generic permission lists that you can add to and remove from role definitions. Suppose you have three 8-hour shifts at your site. Using the modular approach, you could create three different versions of sign-in permissions: one for 6 a.m. to 2 p.m., one for 2 p.m. to 10 p.m., and another for 10 p.m. to 6 a.m. Then, depending on the shift for a particular role, you can easily apply or remove the appropriate permission as needed without affecting any other permissions. Although how you decide to implement Permission Lists depends on your site's security scheme and your security administrator, the modular approach provides increased scalability. As a general rule, your permission lists should be assigned to roles so that the common user has between 10 to 20 lists. This range represents the best balance of performance and flexibility. If you have too many permission lists, you may notice performance degradation, and if you have too few permission lists, you may sacrifice flexibility.
Viewing Content References Select PeopleTools, Security, Permissions & Roles, Permission Lists, Pages to access the Pages page, then click the Edit Components link to access the Component Permissions page.
Page 69 of 90

When you set component permissions and web library permissions, use the View Content References link to view the content references pointing to a given component or script. PeopleTools automatically propagates changes to permission lists to the content references. When you click the link, the Content References page appears, showing the following: Name of the portal. Name of the content reference. The label. Whether or not it is accessible. The path.
Synchronizing Permission Lists and Content References Use the PORTAL_CSS application engine program to synchronize permission lists with content references for the portal. By default, the system synchronizes changes in permission lists with content references; however, after an upgrade or any time when you want to make sure, you can run the PORTAL_CSS program. There is a process definition of the same name.
Adding Links
Select PeopleTools, Security, Permissions & Roles, Permission Lists, Links to access the Links page. Use this page to add links to other pages within your PeopleSoft system that pertain to a particular permission list. For example, perhaps a PeopleSoft application requires a specific security setting to be attached to a permission list. If this application-specific setting appears on a page not in PeopleTools, Security, add a link to that page so that anyone updating the permission list can easily navigate to it. You create your inventory of links to security settings that exist outside of PeopleTools Security using the Security Links page. After being created and assigned
Page 70 of 90

to a security definition, such as a permission list, then the links appear in the security definition's list of links. Running Permission List Queries Select PeopleTools, Security, Permissions & Roles, Permission Lists, Permission List Queries to access the Permission List Queries page. Permission list queries enable you to run queries that provide detailed information regarding a permission, such as the user IDs and roles associated with a permission list. The available queries are documented on the page.
Page 71 of 90
Pages Used to Define Permission Lists Setting General Permissions
Setting Page Permissions
Page permissions refer to the pages to which a user has access. Pages are contained within components, which are ultimately contained within a menu name. To grant access to a particular page, determine the component it is in and the menu name the component falls under. This enables you to drill down to the appropriate page. After you add a menu name, you grant access to its components and pages on an item-by-item basis. In PeopleSoft applications, menu items represent components. If Page 72 of 90

a component consists of more than one page, then selecting the menu item opens another layer with more itemsindividual pages. For example, if you added the UTILITIES menu name to a permission list, you could then grant access to the Utilities, Use menu items but not to the Utilities, Process menu items. Or you could grant access to only a few of the Use menu items, or make some items display only. There are two categories of components to which you grant access permission: All PeopleSoft applications. Page-driven PeopleTools.
Granting Access to Components and Pages The following procedure describes how to set access permissions to your PeopleSoft applications and your page-driven PeopleTools. You begin at the component level and drill down to the page level making the appropriate selections as you go. To add access to PeopleSoft components and pages: 1. Locate the menu name of the component to which you want to add access. 2. Click Edit Components. The Components page appears. 3. Locate the component to which you want to grant access. By default, when adding a new permission list, no components are authorized. 4. Click the Edit Pages button associated with each component to which you want to grant access. The Page Permissions page appears. You specify the actions that a user can complete on the page. You have the following options for each page that appears in the Page column: Authorized? Select to enable a user to access the page. Decide the degree to which a user is authorized on a page by selecting Display Only or one or more of the available options in the Actions group.
Page 73 of 90

Display Only. Select to enable the user to view the information provided by the page, but not to alter any data. Actions. Specify how users can alter information on a page, such as Add, Update/Display, and Correction. The available options depend upon the options selected when the page was initially developed in PeopleSoft Application Designer. To grant access to all pages and all actions for each page, click Select All. 5. When you have finished making the appropriate selections, click OK on the Page Permissions page, and then again on the Component Permissions page. Repeat each step for each menu name.
Setting PeopleTools Permissions
The PeopleTools Permissions section of this page applies to standalone PeopleTools applications. They aren't Pure Internet Architecture-based, but are Microsoft Windows programs that weren't developed using PeopleSoft Application Designer. They include: Page 74 of 90

PeopleSoft Application Designer. PeopleSoft Data Mover. PeopleSoft Definition Security. PeopleSoft Query (Microsoft Windows interface, not the browser interface).
To grant access to these PeopleTools features, select the check box next to the appropriate item. With PeopleSoft Application Designer, the procedure for applying permissions is slightly more complex, because security for PeopleSoft Application Designer also controls what object definition types can be accessed and what degree of modifications can be made. The links on this page (Definition Permissions, Tools Permissions, and Miscellaneous Permissions) enable you to provide more detail to PeopleSoft Application Designer access permissions.
Page 75 of 90

Definition Permissions Select Definition Permissions to access the Object Permissions page.
Tools Permissions In addition to object definitions, PeopleSoft Application Designer security also involves a collection of tools, such as Build and the PeopleCode Debugger, to which developers need access. The tools within PeopleSoft Application Designer include the following: Build/Data Admin (select Build, Project and Tools, Data Administration). Change Control (select Tools, Change Control). Language Translations (select Tools, Translations). PeopleCode Debugger (select Debug, PeopleCode Debugger Mode). SQL Editor (the PeopleSoft Application Designer utility for adding SQL objects and statements to applications and application engine programs). Upgrade (select Tools, Upgrade). This includes Copy Project, Compare and Report, and so on.
Page 76 of 90

You can set the access level individually for the Tools Permissions page options or your can use the (ALL) buttons to set across the board settings. Remember that every button affects every access level for the tools.
Setting Component Interface Permissions
Setting Query Permissions
The Query page has links to the Permission List Access Groups page, where you can define the records to which the user can have access in PeopleSoft Query, and the Query Profile page, where you can define the query operations that the user can perform. Defining Access Groups Click Access Group Permissions to access the Permission List Access Groups page.
Page 77 of 90

Access groups are nodes in a query tree, which you build with PeopleSoft Tree Manager. After youve 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 tablesthe order table and the customer prompt tablein 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 youve 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 treein other words, to all record components in the tree. 4. (Optional) Clear the Accessible check box. To grant access to most of the record components in a high-level access group, but restrict access to one of the lower-level groups, you can add a new Page 78 of 90

row for the lower-level access group and clear the Accessible check box. Users can then access all record components within the higher-level group except for those you explicitly made inaccessible. 5. Save your changes. Defining Query Profiles Access the Query Profile page
Query profiles specify available query operations. You can give users the right to run queries but not create them, or to create regular queries but not workflow queries, and you can restrict the SQL operations that users can perform. You control these options through the query profile. Each permission list has its own query profile, and the combination of all permission lists that are assigned to a role determine the total query access for the role. User profiles inherit query access only through the roles that you assign to them.
Page 79 of 90
2.4
Setting Up Roles
Roles are an intermediate object that exist between permission lists and user profiles. Roles aggregate permission lists so that you can arrange permissions into meaningful collections. If you implement dynamic roles, then you can add permissions to users dynamically, which reduces administration tasks. Role users are the user profiles or users that have membership in a particular role. Users inherit most of their permissions from the roles assigned to the user profile. However, you assign the following permission lists directly to a user profile: Data permissions. These are assigned through a primary permissions list or a row security permissions list. PeopleSoft Navigator homepage permissions. Process profile permissions.
When you assign roles to profiles manually, through the Security pages, these users are called static role users. Other users may obtain membership in a role programmatically. You can run a batch process that runs predefined role rules and assigns roles to user profiles according to these rules. This approach is called dynamic membership, and users who become role users of a particular role programmatically are dynamic role users. Use dynamic role assignment to make your security system scale to large user populations. If you have thousands of users and need to make every change to a user profile manually, the security administrator becomes a bottleneck.
Page 80 of 90
2.5
Administering User Profiles
User profiles define individual PeopleSoft users. You define user profiles and then link them to one or more roles. Typically, a user profile must be linked to at least one role to be a usable profile. The majority of values that make up a user profile are inherited from the linked roles. You define user profiles by entering the appropriate values on the user profile pages. The user profile contains values that are specific to a user, such as a user password, an email address, an employee ID, and so on.
2.6
Implementing Query Security
This chapter discusses how to: Define query profiles. Build query access group trees. Work with query trees. Define row-level security and query security records
Defining Query Profiles

Query takes advantage of user's security settings, row-level security, and primary permission list. Query is a PeopleTool that helps you build SQL queries to retrieve information from your application tables. For each Query user, you can specify the records they are allowed to access when building and running queries. You do this by creating Query Access Groups in the Query Access Group Manager, and then you assign users to those groups with Query permissions. Keep in mind that Query permissions are enforced only when using Query; it doesn't control runtime page access to table data.
Page 81 of 90
Building Query Access Group Trees

Trees are a graphical way of presenting hierarchical information. PeopleSoft Query uses query access group trees to control the access of the tables in the PeopleSoft database. You define a hierarchy of PeopleSoft record definitions, based on logical or functional groupings, and then give users access to one or more nodes of the tree. Users can retrieve information only from those tables whose record definitions to which they have access. You create and update query access group trees using Query Access Manager. To get you started, weve included some sample query access group trees with the PeopleSoft applications. Which trees you have depend on which PeopleSoft applications youve 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 youre familiar with the concept and terminology of PeopleSoft trees. Query Access Group Tree Considerations You should create query access group trees based on your organizations needs and on any customizations youve 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 dont all have to be in the same query tree. One strategy is to use the sample query trees to provide access to the standard PeopleSoft record definitions, but create separate query trees for record definitions that you add in the course of customizing the system. This way, you take advantage of the sample trees but avoid overwriting your changes during future upgrades.
Page 82 of 90

How you organize the contents of the query tree depends on the needs of your organization and your users. For example, you might want to create small trees that are not intimidating to non-technical or casual users. The sample query trees provided in the PeopleSoft application are divided by functions, but to simplify the trees, you may want to create separate trees that contain subcategories of each function. For example, you could create separate trees for U.S. and Canadian record components to grant users in each region security access to only the record components they should use.
Working with Query Trees

This section provides an overview of Query access group trees and discusses how to: Open Query access group trees. Define the Query tree. View and modify definitions.
Opening Query Access Group Trees

To open a Query tree definition: 1. Select PeopleTools, Security, Query Security, Query Access Manager. 2. On the Basic Search page select your search criteria. You can search by Tree Name, Tree Category, Tree Description, Group Name used in a Tree, or Record Name used in a Tree. 3. Click Search. After clicking Search, a list appears containing the definitions that meet your criteria. 4. Double-click the appropriate definition. The list of trees in the lower part of the page also serves as a maintenance utility enabling you to Delete or Copy a tree. If you click Delete, the system
Page 83 of 90

prompts you to confirm the action, and if you click Copy, the system displays the Copy Tree page where you can select a name for the copied tree.
Defining the Query Tree

Before you can insert nodes for access groups and record components, you must first define a number of important characteristics for the tree. Access the Tree Definition and Properties page by selecting Create a New Tree on the Basic Search Page
Viewing and Modifying Definitions
Page 84 of 90
Defining Row-Level Security and Query Security Records: By default, when you give Query users access to a record definition, they have access to all the rows of data in the table built using the associated record definition. In some cases, though, you want to restrict users from seeing some of those data rows. For example, you might not want your human resources staff to have access to compensation data for vice presidents or above. In other words, you want to enforce row-level security, which is offered by many PeopleSoft applications. This section describes the relationship between row-level security and Query security record definitions. Row-Level Security With row-level security, users can have access to a table without having access to all rows on that table. This type of security is typically applied to tables that hold sensitive data. For example, you might want users to be able to review personal data for employees in their own department, but not for people in other departments. You would give everyone access to the PERSONAL_DATA table, but would enforce rowlevel security so that they could only see rows where the DEPTID matches their own. PeopleSoft applications implement row-level security by using a SQL view that joins the data table with an authorization table. When a user searches for data in the data table, the system performs a related record join between the view and the base table rather than searching the table directly. The view adds a security check to the Page 85 of 90

search, based on the criteria youve 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 users 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 panels 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 tables 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 youll want to select is the same one you use as the search record definition for the panel that manages this table. If youre 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 youve designed your own security scheme, select a record definition that appropriately restricts the rows a query will return.
2.7
Definition Security
We will discuss Definition security. Definition groups and permission lists. Definition security rules. Page 86 of 90

You can restrict developer access to the record definitions, menu definitions, page definitions, and others that make up your applications. Just as you use Security to control who can access the PeopleSoft pages in your system, you use Definition Security to control who can access and update PeopleTools definitions. There are two tasks involved with definition security: Creating definition groups. Linking definition groups to predefined permission lists.
Definition Security settings also works at the field level. To change a field on a record, you must be authorized to update all record definitions that contain the field. For example, to update or rename the EMPLID field on any record definition, you must have access to every record definition that contains the EMPLID field. If you are denied access to the ABSENCE_HIST record definition, which contains EMPLID, you wont 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, youve created a permission list for analysts who support the PeopleSoft Payroll module, and you call it PAYROLL_DEV. The analysts are allowed to update only payroll definitions. Using Definition Security, you create a definition group containing only payroll definitions, and give it a name, such as PAYROLL_OBJ. Finally, you link PAYROLL_OBJ to PAYROLL_DEV. You can assign multiple definition groups to a single permission list. You can't declare directly that a particular permission list can modify a specific definition type. You do so indirectly by creating a definition group that consists solely of the desired definition type. Also, remember that you can assign a definition to multiple groups as needed. To ensure total definition security, assign every definition to at least one definition group.
Page 87 of 90
Activity 2.1 - Navigate

Navigate through Peoplesoft HRMS security structure.
Activity 2.2 Creation of permission list, role and user id

Create 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 Trees
In 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 todays date for the effective date
5. Click Save As.

Page 88 of 90

6. Click Close. 7. Select Tree Manager, Tree Manager. 8. Enter DEPT_SECURITY in the Tree Name field.
9. Select the DEPT_SECURITY tree with SHARE as the setID and todays date as the effective date.
10. Expand the ALL DEPTS folder. 11. Click 42000 Corporate Headquarters.
12. Click the Insert Child Node icon to insert a new child node.
13. Enter 44000 as the tree node, and click Add.

14. On the Department Profile page, enter values.
15. Click OK. 16. Click on 63000 Fire Department, and click the Cut button. 17. Click on 44000 Northwest Division, and click the Paste as Sibling button. 18. Click Save. Results Department 63000 now displays as a sibling of department 44000:
Department security tree after moving nodes
Page 89 of 90

Updating Data Permission Security
1. Select Set Up HRMS, Security, Department Security, Update Dept Security.
2. Select DeptSecurity for the run control.

3. Enter the following values: Update Row Level Security -- Selected As Of Date -- Todays 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

Book 6 Workflow - Security-1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Book 6 Workflow - Security-1

Uploaded by

Copyright:

Available Formats

PeopleSoft Workflow and Class Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow Technology Overview

PeopleSoft Workflow and Security

UNDERSTANDING PEOPLESOFT WORKFLOW:

PeopleSoft Workflow and Security

represent activities in the overall business process. Arrows indicate

Figure 3 Sample Activity including a Business Event and Worklist Routing

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

The 8 steps of workflow development.

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Business Processes Page 11 of 90

PeopleSoft Workflow and Security

Activity with workflow routings

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Events and routings icons

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Setting Step Attributes

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Defining Roles and Users

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Defining Worklist Records

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Defining Event Triggers

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

&TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training", BUSACTIVITY."Request Course", BUSEVENT."External Course Request"); end-if;

PeopleSoft Workflow and Security

PeopleSoft Workflow and Security

Using Batch Workflow Processing