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.

Understanding Roles and 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.

User List Roles

PeopleSoft delivers a set of default user-list roles corresponding to the levels within an organization, such as EMPLOYEE, MANAGER, and VICE PRESIDENT. These roles are intended primarily for use with route controls.

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

• It doesn’t matter which person performs the work that is assigned to the role. For example, if a training clerk enrolls employees in classes, the TRAINING CLERK role can be defined as a list of users, because it doesn’t matter which clerk enrolls an employee in a class. The system forwards enrollment requests to the worklist for training clerks, and the first clerk who selects the request handles it. (In PeopleSoft Workflow terminology, the users are working from a pooled worklist.)

• You want everyone who fills the role to receive the same set of work items. For example, if you want the automated Worklist Monitor to send email messages to several people when worklist volumes become too high, you can route messages to a role called SYSTEM ADMINISTRATOR. Every administrator receives the messages.

• Only one person fills the role.

  For example, the CHIEF FINANCIAL OFFICER role can be a user list, even though the list is very short.

See Also

Setting Up Roles

Query Roles

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

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

Because of the flexibility they bring to business processes, query roles are more common than user list roles.

When you create a query role, you tell the system how to determine who fills the role at runtime. You don’t need to assign role users to the role, as you do with user list roles. However, you must set up the query by:

1. Writing a query in PeopleSoft Query. The query identifies the users to whom the work item is routed. The query must take a value from the page that triggers the event, such as the user’s user ID or employee ID, and return a list of role users.

2. Defining the role through PeopleSoft Security Administration. For query roles, you pick the query that you want to run.

3. Assigning the role to the appropriate workflow routings. Because the query has runtime bind variables, you must also specify which page field values to copy into the query.

Route Controls

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

Case Study: The Manager Query Role

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

The Query Selects Role User IDs

The system uses role queries to determine which role users receive the work items. Therefore, the role query should select only ROLEUSER, from either the ROLEXLATOPR or ROLEUSER record definition. No matter how complex the query is—how many joins or selection criteria it has—it must return ROLEUSER only.

Bind Variables Correspond to the Contextual Factors

You define a role as a query because you want to route items differently based on the context of the transaction that the user is performing. So every role query contains at least one bind variable with a value that is set at runtime. The bind variables correspond to the data on which you want to base the routing decision. In our example query, we want to route requests differently based on the EMPLID of the requester, so we should include a bind variable to set the EMPLID.

Note. At runtime, the system sets the values of the bind variables based on data from the page that triggers the routing. When you create the query, make sure that each bind variable matches a field from the page.

Defining a Role Query

To define a role query:

1. Select Reporting Tools, Query, Query Manager, Create New Query.

2. Select the Workflow record definition that you want to query.

   A role query returns a set of role users, so the record definition that you want is either ROLEUSER (which lists role users and the role to which they are assigned) or ROLEXLATOPR (which lists role users and their IDs).

3. Select ROLEUSER as the only SELECT field.

4. Specify the criteria for finding role users.

   For example, to define the manager role, join the ROLEXLATOPR record definition with a record definition that identifies each user’s manager.

   Because you create query roles to route items differently based on the context (for example, which employee created the item) the query usually includes at least one runtime prompt. The runtime prompts (or bind variables) correspond to the data on which you want to base the routing decision. At runtime, the system sets the values of the variables based on data from the page that triggers the event.

5. Select Properties.

6. Select Role as the query type.

7. Save the role query using a name that begins with [ROLE] so that you can identify it as a role query.

See Also

Enterprise PeopleTools 8.46 PeopleBook: PeopleSoft Query

Maintaining Roles and Role Users

This section provides an overview of roles and role user maintenance and discusses how to maintain user workflow information.

Understanding Roles and Role User Maintenance

Role users are the people who participate in automated business processes. Because role users must all have PeopleSoft user IDs, maintaining role users is typically a security administrator’s task.

Note. Workflow applications might involve role users who do not have access to the PeopleSoft system. For example, if the order processing workflow delivers electronic order forms to vendors, the vendors are role users. Those users still need PeopleSoft user IDs with information such as email address. Be sure that the security profile that is associated with the user ID doesn’t allow access to the PeopleSoft system by leaving the password field blank in the user profile.

Maintaining User Workflow Information

The component used to maintain user IDs includes a page specifically for workflow information.

To maintain user workflow information:

1. Select Security, Permissions & Roles, Roles, Workflow to access the User Profiles - Workflow page.

2. Select the following options as needed.

See Also

Specifying Workflow Settings