Peoplesoft Workflow Tutorial

For the pdf training content Click here : PeopleSoft Workflow PPT

4. Define Roles and Users

Define users’ roles when you give them their user IDs. Roles are important in PeopleSoft 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. We can define a role as:

User list roles – a fixed list of individual role users (eg. SYSTEM ADMINISTRATOR)
Query roles – a query that selects role users at runtime (eg. ROLE QUERIES)
Route controls – a routing factor that selects user at runtime (eg. Department)

Note :
Rules – Govern the business process
Roles – Defines which person fits into our Workflow
Routings – Determines which role owns the process at each step

5. Create a worklist record

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.

Entries in worklist are stored in database tables. You define the structure content of these tables by creating worklist records.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.

Although both types of entries appear in the manager’s worklist, the underlying data is different. The course enrollment entries might display information about the course name and start date, while the orders might have information about the descriptions and prices of ordered items.

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.

Entries in worklist 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).
• Display relevant information about each work item on the Worklist page so that users can select the item on which they want to work.
• Retrieve the record that is associated with the work item so that the user can work on it.

System Fields

The first fields in a worklist record definition must always be the following system fields:

System Field	Description
BUSPROCNAME	The business process that includes the work item.
ACTIVITYNAME	The activity that triggers the worklist routing.
EVENTNAME	The business event that triggers the worklist routing.
WORKLISTNAME	The worklist in which the work item is waiting.
INSTANCEID	The system-assigned ID for the work item.
TRANSACTIONID	The system-assigned transaction ID for the work item. When an event triggers multiple routings, each work item has the same transaction ID, but a different instance ID.

The system uses these fields to link the items in the worklist with their tracking information, which is stored in the PeopleSoft-defined table PSWORKLIST. They must be defined as ascending key fields in the worklist record definition.

Virtual Approver, a specialized type of workflow used for approval processes, requires one additional system field. If you are using Virtual Approver, you must also add the APPR_INSTANCE field as a non-key field in the worklist record definition. This field stores the ID assigned to the work item for Virtual Approver processing.

Application Fields

The next set of fields in a worklist record definition are those specific to the application that creates the worklist. The system uses these fields to retrieve the associated record from the database when the user selects a worklist entry and moves to the page where the work is done. Note that:

• Because the system uses the values from these fields to search for the associated database record, you must include all of the key fields for the search record.
• Application field names cannot be the same as key words used in field mapping.
• All of the application fields appear in the user’s worklist, unless you suppress them by including the special field WORKLIST_DESCR.

Worklist Display Fields

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

Worklist Display Field	Description
WORLKIST_URL	The text that links to the page where the user can work on the item. Appropriate values might include the key data for the record in which the item will be worked. For example, for a work item directing a manager to approve an expense report, the text might be the name of the employee who submitted the report.
WORKLIST_DESCR	A text comment that appears in the user’s worklist. The presence of this field automatically suppresses the display of any application fields, although the key fields are still used to bypass the search page of the target page. On the Worklist Details page, these values appear as the Link and Comment fields. The link also appears on the main Worklist page.