Defining a Rule Step

This section discusses how to define a rule step:

This example illustrates the fields and controls on the Rule Step Definition dialog box - Definition tab.

To define a rule step:

1. Double-click the rule step icon, or right-click it and select Item Properties.

   The Rule Step Definition dialog box appears.

2. Enter an icon description.

   Use the Icon Descr field to specify a description to appear in dialog box boxes that list this type of map. If you leave this field blank, the map name appears by default.

3. In the Route to Role list box, select the role that performs this step.

   The role that you select is the role of the user who approves items at this step and path. The system verifies this role against the row-level rule that you set up in a previous step before routing items. Select a user list role that corresponds to a level within your organization. In approval processes, a person’s level typically determines the approval authority.

   Note:

   The Virtual Router portion of Virtual Approver determines who should receive the work item based on the role that you specify here, with the query role that is assigned to the worklist in PeopleSoft Application Designer. The worklist's query role must accept a role name as a bind variable, as the standard route control roles do.

4. In the Equally Authorized Roles field, select all of the roles that are qualified to process the transaction at this step.

   For example, consider a purchase request process in which managers can approve transactions up to 25,000 USD. If a manager enters a request for 25,000 USD or less, Virtual Approver automatically approves it. Now, suppose that you also want to allow system administrators to self-approve up to 25,000 USD (if you allow self-approval). All you do is add SYSTEM ADMINISTRATOR to the Equally Authorized Roles box. System administrators don’t receive transactions routed to them, but they are treated as managers for the requests that they submit.

   You can also use this field for users who do not normally participate in the approval process, but who have the necessary authority to approve at this level. This can be useful for exception processing, for example, when the regular approver is unavailable or you need to approve a transaction outside the worklist. Be aware that even if an equally authorized user handles the approval, the worklist routing in the regular approver’s queue does not disappear.

   GetApprovers does not return information about equally authorized roles, only about users who actually perform approvals.

   Use the Add and Remove buttons to add users to or remove users from the Equally Authorized Roles box.

5. Specify what the user sees when a transaction requires further processing for approval.

   When a transaction needs further approval, Virtual Approver can:

   • Trigger the specified event to forward the transaction to the next step.

   • Display a message to the user, indicating that further approval is required.

6. Specify which of these actions Virtual Approver should take by selecting one of the options in the On Further Processing box on the right-hand side of the page. The default is Both.

   Field or Control	Description
   Workflow Only	If a transaction needs further approval, Virtual Approver forwards it on to the next step without informing the user.
   Message Only	The user sees a message indicating that the transaction needs further approval, but the transaction does not enter the workflow.
   Both	Virtual Approver displays a message asking the user whether to add the transaction to the workflow. If you select Message Only or Both, the message comes from the PeopleSoft Message Catalog. Use the Message Catalog setting to specify the set and number of the message that the user sees.

7. Specify whether the system can bypass this approval step if additional approval is required.

   In the Skip to Next Step group box, select when, if ever, the current approver should be ignored:

   Field or Control	Description
   Yes	If additional approvals are needed, the system always bypassses this approver. Use this option only when role users can self-approve certain transactions but do not ever approve other people’s transactions.
   No	This approval step is not skipped and the routing occurs, regardless of whether additional approvals are required. This step is omitted only when a prior approver was able to give final authorization.
   Only skip if cannot authorize	If additional approvals are needed (that is, this approver does not have final approval authority), the system skips this approver.

8. In the Appr Step (approval step) and Appr Path (approval path) fields, specify which step you are defining.

   Approval processes can have multiple steps (in sequence) and multiple paths (in parallel). The purchase request example following this procedure has several steps, but only one path. An example of a process with multiple paths is one in which requests must be approved by the department manager and an office manager before going to a vice president. Here is the sequence of steps and paths in this case:

   Step	Path	Route to Role
   1	A	MANAGER (DEPARTMENT)
   1	B	MANAGER (OFFICE)
   2	A	VICE PRESIDENT

   In this example, the system sends two worklist entries when a new request comes in: one to the department manager and one to the office manager. When both of the managers approve the request, the system forwards it to a vice president.

   Note:

   The easiest way to determine approval steps and paths is to consult the activity map for the business process for which you are defining approval rules.

   Note:

   The approval step definition allows for up to 99 steps to be available when you are defining an approval process in Application Designer. However, you can enter any step number required.

   Note:

   No mechanism in Virtual Approver exists by which the worklist entry is removed from other parallel approvers when using multiple steps in case of deny or recycle.