Approval Rules

The Approval Rules (IWF08) page is where the workflow rules are defined for transaction processing. Rules are selected based on the Transaction Code and the organizational values (see examples in the "Approval Hierarchy" topic). The applicable rule is the one that most specifically matches the organizational values. Once a rule has been found, it is evaluated to determine if approvals are required. If no applicable rule is found, then the transaction does not require approvals and it is marked as having completed the approvals phase of Workflow. The transaction is then either processed to Final or remains as Pending for submission by the System Maintenance Utility, based on the Workflow Asynchronous Process setting on the Transaction Control page.

Note: Regardless of the Workflow Asynchronous Processing setting, if the transaction rejects during final workflow approval submission, the transaction will revert to Draft Phase and will need to be corrected and resubmitted to Pending, and go through workflow again.

Each Approval Rule can require up to 15 levels of approval, and each level consists of up to five approval conditions joined with logical OR connections. If any of the approval level’s conditions evaluates to true, then that approval level is required. If any approval level is required, then the transaction requires approval(s) and enters approval processing for all required approval levels.

Field	Description
Transaction Code	A required Transaction Code that instructs the system what conditions can be selected.
Organizational COA (9)	The organizational values for the approval rule. The default value, ????, is a wild card and matches any value. Two examples are given to demonstrate the use of these fields: Department is entered as 010 and Approval Level 1 is completed with Routing Sequence, Assignee ID, and Worklist Comment (at a minimum); this will result in all instances of the Transaction Code where the Transaction Department is 010 will go to the Assignee ID. There are no conditions in this example to show how the Organizational COA can be used as approval fields. Two rules exist where the transaction amount is found to be greater than $1000.00 where one rule is to Department 010 and the other is to Department 020. In this situation, any instance of the transaction over that amount will go to different approval roles or approval users based on the Transaction Department. This reduces approval setup by not needing two different conditions where the amount is the same in each but the Transaction Department is different. Two records are required each way, but just a preference of setup.
Self-Approval Restriction	The restriction associated with approving a transaction that a user has created and/or submitted. The restrictions can be one of the following: No Restriction Creator Restricted Submitter Restricted Creator / Submitter Restricted The default value is defined by the SELF-APPROVAL_DEFAULT_VALUE record on Application Parameters.
Enforce Single Approval	If this check box is not selected then a single user is allowed to apply multiple approvals to the same transaction. This indication is only read if the Single Approvals Enforced check box on the Transaction Control page is unchecked. If the check box on Transaction Control is checked an informational message is issued during an update action on the Approval Rules if Enforce Single Approval is unchecked.
Notify Batch Submitter	Select this check box if you want the submitter of transactions submitted by batch jobs to be sent an email notification as soon as an approval level assignment occurs (provided Additional Notification on Approval Level is setup to send emails to Submitter).
Notify Creator	Select this check box if you want the creator of transactions to be sent an email-notification as soon as the transaction goes to Pending. This notification can be particularly useful in scenarios where creator and submitter are different.
Send Resubmit Notification	Select this check box if you want to send a notification to the original submitter and the previous downstream approvers of a transaction when any transaction is resubmitted having previously been rejected back to Draft. This action also updates the approval sheet to include the new notifications.
Recall Maximum Routing Sequence	The system allows the submitter to recall the transaction from Pending to Draft from any specified routing sequence, if the Recall Maximum Routing Sequence field value is equal to or less than the current routing sequence of the transaction that is waiting for approval.
Rejection Comment Required	If checked and a user selects either the Reject or Reject All actions, then the system will require that user to populate the Subject and Comment fields before the transaction is successfully rejected. This setting bypasses the setting of the WF_BYPASS_COMMENTS_PG_ON_REJECT parameter on the Application Parameters page. Therefore, even if WF_BYPASS_COMMENTS_PG_ON_REJECT is set to N, if Rejection Comment Required is checked on the Approval Rules, then a Subject and Comment must be entered to reject.
Effective From / To	Optional dates to control when an approval rule begins or ends.
Notify Submitter	If checked, a transaction rejection notification email will be sent to the submitter when the submitted transaction has been rejected back to the Draft phase.

Field	Description
Routing Sequence	Defines the sequence in which the approval routings occur. Approval levels need not be ordered sequentially (for example, level 1, then level 2, then level 3, and so on). Approval routings can occur in any order and may be done in parallel (for example, level 2, then level 1 and 3, then level 15, then level 5, and so on). Set the Routing Sequence to 0 if the approval level is not required (in this case no routing to the Approval Level takes place and all field values setup on the Approval Level are ignored).
Priority	Priority value assigned to a workflow rule that is intended to provide information to approvers looking to take transactions from a worklist.
Email Assignee / Role	When checked, an email will be sent to a user (if the assignee is a User ID) or all members of the Approval Role (if the assignee is an Approval Role) at a given approval level. It can be used to notify the Assignee that the transaction is routed to the given Approval Level (it can occur with Approve, Reject, Unapprove actions, and so forth.).
Condition 1 to 5	Determines which conditions are evaluated for the approval level. If any of these conditions evaluate to true and the Routing Sequence is not 0, then this approval level is required.
Approval Rule	The logical rule associated with the workflow approval conditions that must be met for the indicated Transaction Code to be submitted for the selected approval level. The value is a concatenation inferred from the Approval Rule record.
Assignee ID	The User ID for individual approval or the Approval Role ID has the Assignee Is a Role flag checked. If the Assignee ID is populated, the Assignee Field must be blank.
Assignee Is a Role?	An indication that among driving edits, determines if the Assignee ID field is to capture a User ID (unchecked) or an Approval Role ID (checked).
Assignee Field	Allows the selection of transaction Header fields where User IDs are recorded to be used for workflow instead of the Assignee ID for each approval level. To facilitate the routing of HRM transactions by Supervisor ID, when the selection of routing by Assignee Field is made on Approval Rules, the WF SUPR INFER TYPE SPAR entry is used to determine which User ID should be used for workflow routing; the Supervisor User ID established on Department Specific Data (DEPTD) (Text Value = D), or the incumbent’s User ID of the Reporting To Position on Position Maintenance (PSMT) (Text Value = P). The system first attempts to infer the Supervisor User ID. However, if a Supervisor ID is not found on Department Specific Data, then the system infers the incumbent’s User ID of the Reporting To Position on Position Maintenance.
Worklist Comment ID Worklist Comment	A required field to put a comment into the workflow inquiry pages for the approval level. The comment text is inferred from the Manage Approval Comment reference page for informational purposes.
Additional Notification	An indication to send a notification to the creator and/or submitter of a transaction if the transaction is assigned for an approval at the selected level (it can occur with Approve, Reject, Unapprove actions, and so forth). Valid values for this field are: None Submitter Creator Both The Additional Notification must be set to None, if the selected level does not require approvals (that is, Assignee ID). For transactions submitted with batch processes, notification emails to Submitter is only sent when Notify Batch Submitter is selected.
Non-Approval Notification	An indication that a notification email should be sent to a User, Role or Variable, as defined in the Non-Approval ID field when the transaction reaches the selected Approval Level (it can occur with Approve, Reject, Unapprove actions, and so forth). The feature can be used to send an email to any person(s) notifying about the transaction reaching the selected Approval Level. The notification is sent when a level is evaluated as true (Conditions are satisfied), regardless of whether the transaction is also being routed for Approval at the selected level. If checked, the Routing Sequence must be populated with a value between 1 and 15 and the Non-Approval ID, Non-Approval ID Type, and Non-Approval Comment ID must be populated. It is possible to setup an Approval Level only for notification (to send email to other person indicated by Non-Approval ID) and not for routing by setting up Routing Sequence, Condition (if any) and Non-Approval Notification fields and leaving Assignee ID blank. In this situation, when a transaction reaches the Approval Level it will send a notification email and then route to the Approval Level at next Routing Sequence.
Non-Approval ID Type Non-Approval ID	The ID of the User, Role, or Variable that will receive a non-approval notification. The following rules apply: If the Non-Approval ID Type is User ID, then the Non-Approval ID must be a valid user on the User Information page. If the Non-Approval ID Type is Role ID, then the Non-Approval ID must be valid role on the Approval Role page. If the Non-Approval ID Type is Variable, then the Non-Approval ID must be valid on the Notification Variables page.
Non-Approval Comment ID Non-Approval Comment	A required field when the Non-Approval Notification is checked to put a comment into the notification to the Non-Approval ID for the approval level. The comment text is inferred from the Manage Approval Comment reference page for informational purposes.
Automatic Escalation	This field indicates after how many days from the day of assignment of the worklist item, the assignee should be sent a warning email notification if no action has been taken. If assignee is an approval role, an email is sent to all of the members of the role. If assignee is a User OR if role and a member of the role has performed a Take Task on the Worklist Item, an email is sent to the particular user. Refer to the Automated Workflow Escalations run sheet in the CGI Advantage Administration Utilities Run Sheets guide to understand the functionality of the following fields related to warning notification and escalation. To summarize, these fields drive when the batch process should send a warning email notification to an assignee when the worklist item ages beyond the Warning Threshold Age and when it should escalate the item to Escalate Assignee(s) when it ages beyond Escalate Threshold Age 1 and 2. Warning and escalation ensures that the worklist item is worked on by the specified time period by sending email reminders to an assignee and escalating the item to more assignee(s) by creating additional routings to them so that they can work on them.
Warning Threshold Age	Age of the worklist item at Approval Level after which it becomes eligible for Warning Email notifications. Only values greater than zero can be specified. Note: The following condition has to be satisfied that drives the sequence of events on aging: Warning Threshold Age < Escalate Threshold Age 1 < Escalate Threshold Age 2. This means when a worklist item ages beyond Warning Threshold Age, then the first warning email is sent out every time the job is run. If Assignee does not take action on the worklist item and the item ages beyond Escalate Threshold Age 1, then the Automated Workflow Escalations batch job does escalation at level 1. If still no action is taken on the worklist item and the item ages beyond Escalate Threshold Age 2, then the Automated Workflow Escalations batch job does escalation at level 2.
Warning / Escalate Template ID	Template ID to be used for sending the Warning/Escalation e-mail at approval level. The content of the template forms the body of the e-mail notifications to be sent to the users.
Escalate Threshold Age 1 Escalate Assignee ID 1 Escalate 1 Assignee Is a Role	Age of the worklist item at approval level after which it becomes eligible for escalation at Escalation Level 1. Only values greater than zero can be specified. Automated Workflow Escalations batch job calculates the age of a worklist item as the number of days between the Assigned Date of the worklist item and the Application System Date on Application Parameters. If the age of the worklist item equals or exceeds the Escalate Threshold Age 1 but is less than the Escalate Threshold Age 2 (which means the item is not yet escalated at Level 2), then the batch job routes the worklist item to Escalate Assignee 1 asking to take action on the pending Workflow item. After the escalation, both Escalate Assignee and Original Assignee will be able to work on the worklist item through their worklist. When any one of them approves the item, it moves ahead in the Workflow chain. Both Original Assignee as well as Escalate Assignee 1 are notified through e-mail of the escalation action. If Original Assignee is a User then the e-mail notification is sent to the particular User. If Original Assignee is an Approval Role and none of the Role's Approvers has performed 'Take Task' on it then an e-mail notification is sent to all Approvers belonging to that Role. If the task has been taken by an Approver with that Role, then the e-mail notification is sent to the particular Approver only. The Escalate Assignee ID 1 and Escalate 1 Assignee Is a Role fields are used to determine if escalated to a user or an approval role.
Escalate Threshold Age 1 Escalate Assignee ID 1 Escalate 1 Assignee Is a Role	Age of the worklist item at approval level after which it becomes eligible for escalation at Escalation Level 2. Only values greater than zero can be specified. The Escalate Assignee ID 2 and Escalate 2 Assignee Is a Role fields are used to determine if escalated to a user or an approval role.