Considerations for Setting Up Requisition Approval Task

To facilitate the approvals setup process, the following preconfigured requisition approval elements are available:

• Requisition Approval task

• Stages

• Participants

In the Setup and Maintenance work area, use the Manage Requisition Approvals task in the Approval Management functional area to configure requisition approval rules.

The following figure depicts the stages seeded for requisition approvals and also indicates that the stages are seeded in sequence.

Approvals are routed through the seeded stages in the following sequence:

1. Header Preapproval Stage

   The following figure shows seeded participants in the header preapproval stage.

   

2. Header Stage

   The following figure shows seeded participants in the header stage.

   

3. Header Postapproval Stage

   The following figure shows seeded participants in the header postapproval stage.

   

4. Postapproval FYI Stage

   The following figure shows seeded participants in the postapproval FYI stage.

   

There are four seeded stages for requisition approvals and within each stage, there are seeded participants. The non-FYI participants are seeded as rule based, which lets you pick the list builder (Supervisory, Position, Job Level, Single User, User-Defined Routing, and Approval Groups) that's applicable for your organization.

Line and distribution level rules can be defined within the stages with header dimension.

Header Preapproval Stage

This is used to route requisitions for preapproved requisitions, such as emergency requisitions.

Seeded Participants:

1. Requester FYI

   • The requester on every line for a requisition receives a requisition FYI notification. This allows requesters to be notified when a preparer creates a requisition on their behalf. Each requester on every requisition line is notified. The rule to notify the requester is available out of the box, hence you don't need to perform additional steps for this.

2. Preapproval Header Consensus

   • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.

3. Preapproval Header First Responder Wins

   • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject represents the outcome of all remaining approvers.

4. Preapproval Header Hierarchy

   • Approvals are routed in serial for this participant.

Header Stage

The header stage is often used for fiscal approvals, based on the requisition amount.

Seeded Participants:

1. Header Hierarchy

   • Approvals are routed in serial. This participant is generally used for supervisory or position hierarchy-based routing.

   • The approvers returned based on all rules that apply in a serial participant are notified in sequence, even if the rules are evaluated against lines or distributions.

2. Header Hierarchy 2

   • Approvals are routed in serial.

   • If your organization has a requirement to have a second hierarchy-based routing in parallel to the Header Hierarchy participant, rules should be maintained in this participant.

3. Header Hierarchy 3

   • Approvals are routed in serial.

   • Similar to Header Hierarchy 2, this participant allows another hierarchy-based routing in parallel to Header Hierarchy and Header Hierarchy 2 participants.

4. Header Stage Consensus

   • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.

5. Header Stage First Responder Wins

   • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject represents the outcome of all remaining approvers.

How You Use Overriding Approver Attribute

If there are cases where requesters might need to change the starting approver for supervisory-based routings, approval routing rules can be created using the overriding approver attribute at the requisition header level. You can create approval and FYI rules using this attribute, as part of the rule condition or action.

Note:

If you set up the overriding approver attribute, you may also send an FYI task to the original system generated first approver notifying the original approver that they have been bypassed.

Header Postapproval Stage

This is used to route for post approvals.

Seeded Participants:

1. Header Consensus

   • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.

2. Header First Responder Wins

   • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject represents the outcome of all remaining approvers.

3. Postapproval Header Hierarchy

   • Approvals are routed in serial for this participant.

Postapproval FYI Stage

The Post Approval FYI stage is created to send the requisition preparer an FYI notification on the outcome of the requisition approvals.

This stage isn't available in the BPM Worklist or Approvals UI pages for configuration.

Note

You do not need to use all of the seeded stages and participant. However, if you do not need to use any of the seeded participants, you simply need to select the Enable or Disable action for the respective participant on the Manage Approval Task page.