Understanding Roles and Users

This PeopleSoft application 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:

• The role, rather than the specific person, assigned to the task is important. For example, if a training clerk enrolls employees in classes, the TRAINING CLERK role can be defined as a list of users, because any clerk can enroll 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.

Define a role as a query if you want to send work items to different people at different times. When an employee’s manager must approve a training request, the manager role is a query, because you want to send enrollment requests to different managers, depending on who makes the request.

When a role is defined as a query, the system determines who should receive a work item based on the values of fields on the page that triggers the routing. It uses context information from the current record to determine who needs to complete the work. For example, the manager role query uses the value of the Employee ID field from the course request to look up the name of the employee’s manager.

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 do not need to assign role users to the role, as you do with user list roles. However, you must set up the query by:

1. Writing a query in PeopleSoft Query. The query identifies the users to whom the work item is routed. The query must take a value from the page that triggers the event, such as the user 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.

The PeopleSoft Workflow Administrator enables you to define route controls. For example, suppose that you want to route purchase requisitions to different buyers, depending on which vendor supplies the ordered items, which business unit is requesting the items, and which department needs the items. You can define a route control for each factor—vendor ID, business unit, and department—and specify a range of values for each buyer.

When an employee requests an external course, we route the request to the employee’s manager. Because we route requests to different people, depending on who submits the request, we must define the manager role as a query.

A role query returns one or more role-user IDs based on the data that is saved on the page triggering the routing. In our case, we need a query that takes an employee’s EMPLID (which is available on the course request form) and returns the role user ID of the employee’s manager.

This is the SQL statement for the [ROLE] Manager query (with the effective date logic removed for simplicity):

SELECT C.ROLEUSER

 FROM PS_JOB A, PS_DEPT_TBL B, PS_ROLEXLATOPR C

 WHERE B.DEPTID = A.DEPTID

 AND A.EMPLID = :1

 AND C.EMPLID = B.MANAGER_ID