Approval Rules Management for Procurement

The Oracle Procurement Approval Rules Management page integrates with the Approval Management Extension rules engine to enable administrators to organize and author approval routing rules based on numerous seeded document attributes such as requisition amount, ordered amount, price change percent, category and so on.

Based on your unique business requirements, administrators can choose to send the approval request to approvers in parallel or in sequence. Approvals can be routed up a supervisory chain, position or job level hierarchy, to a single approver or a list of approvers. The figure below depicts the key elements that are involved in understanding and setting up approval routing rules.

Document Approval Request Task

In many end-to-end business processes, human intervention is required for activities such as approving documents, managing exceptions, or performing activities required to advance the business process. The document approval request task lets you send approval requests to approvers enabling them to make a decision and thus advancing the request-to-pay business process. Both task configurations and approval rules must be reviewed and completed for each document approval task before submitting documents for approval.

Task Configuration

The Task Configuration page in BPM Worklist Administration lets you set up:

Assignment and Routing Policy

Allow all participants to route task to other participants
1. Selected by default.
2. Companies can control if participants can add other approvers/FYI participants in the approval list.
Allow participants to edit future participants
1. Selected by default.
2. Controls if participants can update or remove participants remaining in the approval list who weren't assigned the approval task.
Allow initiator to add participants
1. Selected by default.
2. Deselect to prevent the person submitting a document or registration from inserting ad-hoc approval or FYI participants.
- Enable auto claim.
  1. Selected by default.
  2. Enabled when a task is assigned to a position, role or a LDAP group. Since there can be multiple users in a position, role, or group, a user has to first claim the task to prevent multiple users from updating the task. This doesn't include approvals based on approval groups. Enabling auto claim won't require a participant to first claim before performing an action, hence reducing the number of steps.
    
    AMX provides the flexibility to include LDAP groups (groups created in the user directory) as participants for approval routing.
  3. If Enable auto claim isn't ON, emails for position hierarchy won't have actionable buttons.
Early Completion Settings
- Complete task when participant chooses Approve or Reject.
  1. Indicates if the approval task should be completed when a Reject or Approve action is performed by a participant.
  2. The default setting for the requisition approval task is to complete the approval task on Reject.
Approval Preconditions
- Mandate comments before updating these outcomes.
  
  Controls if a comment is required when an approver takes the approve action or reject action for a task.
Miscellaneous
- Notify these participants when error occurs.
  
  Lets you define an administrator who will be notified when an error occurs in the approval routing process.

Task Aggregation

If the same participant is returned in the same task or stage, you can select a task aggregation setting to reduce the number of tasks the participant receives for the same requisition. The options include:

Once per task (default setting for requisition approvals)

Within the same task, if a participant is returned multiple times based on the approvals rules, then the participant will only receive one worklist task for action or review.
Once per stage

If the same participant is returned multiple times based on the approval rules within the same stage, then the participant will receive one worklist task per stage for action or review.
None (default setting for purchasing document approvals)

No aggregation will be performed.

Expiration and Escalation Policy

Update the expiration and escalation policies to control when tasks should be expired, escalated or renewed. These policies apply to the entire tasks and not per approver. For instance, if a deadline of three days has been set and there are four approvers then it would mean that all four approvals need to be secured within three days from the time the task was submitted and not allocate three days to each approver totaling to twelve days.

Expiration: If an assignee doesn't act in the time specified for expiration, the task will be automatically rejected.
Escalation: If an assignee doesn't act in the time specified for escalation, the task will be escalated to the manager based on the management chain defined in Oracle Identify Management (LDAP).

Maximum escalation levels specify the number of times the task can be escalated if the approver to whom the task is escalated doesn't act in the time specified for escalation. If the maximum escalation level is reached without any actions, the task will be automatically rejected.
Renewal: You can extend the expiration period when the assignee doesn't respond within a specified time. The number of times the task can be renewed upon expiration and the duration of each renewal will determine how long the task will remain unexpired.

Notification Settings

Notification settings includes these aspects:

Indicates when a user or group is assigned a task or is informed that the status of a task has changed. Notifications can be sent through email, voice message, instant message, or SMS. You can also specify different types of participants to receive notifications for different actions.
You can set up reminders to be sent before task expiration or after task assignment.
You should enable the Make notification actionable option if approvers can take approve or reject actions from the email notifications.
You should enable the Send task attachments with email notifications option if these attachments should be sent as email attachments.