There are several settings that you must configure in AME before you can use the functionality in SSHR.
Also, any custom functions you created prior to release 4.1 will use the customizable PL/SQL package as the default approvals mechanism. However, you can modify any custom SSHR functions to point to AME by adding two new function parameters.
Note: The AME rules and conditions always override any other workflow attribute settings that apply to approvals, for example, the attribute settings for the Review activity. If the Approvals Required workflow attribute is set to Yes for a workflow process but AME does not return any approvers, the process completes without requiring approval. As a general set-up recommendation, you should set up processes that currently do not require approval as follows:
Set the Approvals Required workflow attribute to Yes
Configure AME so that no approvers are returned
If you subsequently need to add approvals to your process, you can simply use a different AME condition.
Use an appropriate AME responsibility to check that the value of the following variables is Yes:
AllowFYINotifications
AllowAllApproverTypes
If the value for this variable is No, you cannot use the Position approver type.
Use the Workflow Builder to set the Timeout value for the Notification activity in your workflow processes.
See: To Define Nodes in a Process
See: Timeout Transitions
If you have created custom workflow processes, use the Workflow Builder to replace the existing notification processes with the new process Notification Process for Approvers and Notifiers.
You define additional function parameters in the Form Functions window. You should also check the workflow attributes for your workflow process using the Workflow Builder.
Query your function.
Navigate to the Form tabbed region.
Add the following parameter information to the Parameters field for your function:
pAMETranType=SSHRMS
pAMEAppId=800
Save your work.
Log on to Oracle Approvals Management using the appropriate AME responsibility.
Select the SSHRMS transaction type.
Select the Conditions tab and click on the WORKFLOW_PROCESS_NAME condition.
Choose the Add Text Value button and enter the name of your new workflow process as an attribute value.
Save your work.
Workflow Processes
Notification Process for Approvers and Notifiers, which includes the following subprocesses:
FYI Notification Process (HR_FYI_NOTIFICATION_PRC)
Approvers Notification Process (HR_APPROVAL_NTF_PRC)
RFC Notification Process (HR_RFC_NTF_PRC)
Avoid Errors When Routing Approvals in Oracle SSHR
Currently, workflow transactions that use the Notification Process for Approvers and Notifiers SSHR approval process end in errors for the following reasons and users cannot track such transactions:
When an approver does not approve a transaction within the time period, the workflow updates the corresponding Oracle Approval Management (AME) transaction type with the No Response status. Then, the workflow tries to route the notification to the approver's supervisor based on the approval chain. If the supervisor is not available, then the workflow displays an error.
If the AME transaction type is incorrectly setup, then the workflow cannot route transaction for approvals. This happens because the workflow uses the list of recipients defined in the transaction type.
Using AME, you can define the adminApprover configuration variable for a transaction type. The adminApprover variable identifies the person or user account that AME identifies as the administrator who can correct the hierarchy issue so that transactions get processed without any errors.
Oracle SSHR notifies the administrative approver identified by AME indicating that an exception has occurred for transactions that use the SSHR approval process Notification process for approvers and notifiers.
The administrative approver receives notifications:
When a user submits the transaction on the Review page, even after receiving the Oracle Approval Management (AME) transaction type incorrect setup error.
When the approval chain is broken and workflow cannot route the transaction to the next approver. For example, the workflow routes transactions from employee A to employee B, and then from B to employee C. Once the approval process starts, C resigns from the enterprise. When employee B approves the transaction, the workflow process sends a notification alerting the administrator about the break in the approval chain.
When an approver does not approve a transaction within the time period, and if a supervisor is not available for the workflow to route the transaction.
Note: If you do not use AME.A or above, the workflow processes are as follows:
Approvals Process with Correction V5.0 (for dynamic approvals)
Approvals Process (for standard approvals)
Configurable Workflow Attributes
| Process Name | Function Name | Attribute Name | Description |
|---|---|---|---|
| FYI Notification Process | Notify | Message Name | Specifies the name of the message for the notification. You can create separate messages for notifications sent on submission of the transaction and on approval, for example. |
| FYI Notification Process | Notify | Expand Roles | To assign this notification to a role consisting of multiple users and to send an individual copy of this notification to each user in the role, select Yes. If you select No, only one copy of the notification is delivered to the role as a whole. |
| FYI Notification Proces | Notify | Performer | The role to whom the notification is sent. You can select a constant role name or an item type attribute that dynamically determines the role at runtime. |
Configurable Profile Options
For information on profile options to control whether users can update pending transactions, see: Further Approvals Options.