Worklist

• Change Role Order: A transition to the Approval Role Display Order page where the display order of all approval roles can be defined or changed.

• Recall: A transition to the Approval Recall page to review those transactions approved by an approver that are still in workflow, and that approval applied is the highest one that has been applied to the transaction thus far. From this page an approval can be recalled (see that action below).

• Worklist Details: A transition to the Worklist Details page, to view any additional details defined for a transaction code. Before using this transition, it is necessary to narrow down a Worklist listing to one transaction code.

• Worklist Pipeline: A transition found on many worklist pages that takes the worklist results to the Worklist Pipeline page to impact other approval levels.

• Manager Worklist: A transition to the Manager Worklist for those approvers that are defined as the manager for the approval role to perform all tasks available from the regular worklist but also a few management functions.

There are many actions available from the grid menu and row menu. Those actions that can only apply to a single transaction are only listed in the row menu. The Worklist widget for Performance Budgeting includes many actions (such as, Approve, Reject All, Take Task, Return Task, and so forth) that allow you to perform the selected action on all records that are selected (that is, the selection check box is selected) in the grid. The Worklist widget for Performance Budgeting also includes a Refresh action, which refreshes the list of transactions on the Worklist widget.

To perform actions such as Approve, Reject, Reject All, and Unapprove, the user must take the workflow item from the approval role worklist to his/her personal worklist using the Take Task action. The Take Task action can be avoided by setting the transactionWorkflowActions feature flag to true, which makes the Take Task action optional for users that belong to the workflow role.

• Approve: This action applies a user’s approval level to the selected transaction(s). The approval is applied to the currently assigned approval level. After the approval action has been applied successfully, the transaction(s) will be removed from your worklist, and routed to the next approver or approval role, if required.

• Unapprove: This action will remove a previously applied approval from the selected transaction(s). It allows you to “take back” your applied approvals. This action is applied to the currently assigned approval level. You may apply an Unapprove action only on a transaction on which a Reject action has occurred, as opposed to Reject, which can be applied on a transaction at any approval level. Furthermore, Unapprove can only be applied on a transaction when the routing Reason is to “Confirm or remove approval’.

• Reject: This action is used to indicate a wish to not approve the currently assigned approval level on the selected transaction(s). The transaction will then be routed back to the approver that previously approved the transaction. The transaction would be routed back to the Draft phase if this is the first approval routing. A Reject action can be applied at any approval level and by any approver, as opposed to Unapprove, which can only be applied on a transaction on which a Reject action has been applied. The Rejection Comment Required indication on the approval rule defines whether a comment is required. The Rejection Comment Required field once set to Yes from the approval rule can also be sent to the recipient through email by giving a value of Y on the ENABLE_REJECT_COMMENTS_ON_EMAIL parameter on the Application Parameter (APPCTRL) page.

• Reject All: This action is used to indicate that you want to remove the transaction(s) from approval processing. This action may be applicable when, for example, the submitter is trying to purchase more items then allowed. Applying this action will reject your and all other approval levels and will route the transaction back to the submitter for corrections. The Rejection Comment Required indication on the approval rule defines whether a comment is required. The Rejection Comment Required field once set to Yes from the approval rule can also be sent to the recipient through email by giving a value of Y on the ENABLE_REJECT_COMMENTS_ON_EMAIL parameter on the Application Parameter (APPCTRL) page.

• Reassign: This action allows you to assign the transaction to another approver. This will remove the transaction from your worklist and add it to the selected user’s worklist. This is different than the Manual Route action, which will keep the transaction in your worklist while also adding it to the selected user’s worklist.

• Take Task: This action moves a transaction or transactions from an approval role to the personal worklist of an approver.

• Return Task: This action returns a transaction or transactions from the personal worklist of an approver to the approval role worklist from where it may be taken by another user. The Return Task is not possible if the current task is in the user’s worklist as a result of any of the following actions: Reassign, Manual Route, Reject, Unapprove, or Recall.

• Manual Route: This action routes the transaction to the personal worklist of another approver. The routed transaction will continue to exist in the original worklist also, as opposed to the Reassign action.

• Bypass Approval: This action allows the transaction(s) to be processed to Final without needing to go through the approval process. The Bypass Approvals action can be applied from inside the transaction or from the worklist. In addition to security that allows the action, bypassing of approvals has to be allowed for a given transaction code on the Transaction Control reference page.

• Track Work In Progress: This action opens a view of the past and future workflow activity of a transaction. The view may be accessed from within the transaction or from a worklist.

• Change Priority: Select this action to change the Priority of a selected transaction or transactions.

• Posting Line Inquiry: This action, which is only available for Financial transactions, transitions to Posting Line Inquiry (PLINQ), filtering records for the selected transaction. The action gives approvers a full view of all posting lines within a transaction version.