You use Oracle Workflow to route and approve position transactions, budget worksheets, and budget reallocation transactions. For non-position control organizations, you route only budget worksheets. If you do not wish to route budgets, you can use the Budget Detail window.
For information about selecting organizations for position control, refer to Creating Organization Hierarchies .
Your organization may route transactions for data entry and approval using different chains of authority. When using workflow for routing transactions, you have a choice of defining a routing sequence based on routing lists, supervisory hierarchy, or position hierarchy.
When routing by routing list, the application determines the next destination on the routing list.
A routing list is a sequence of destinations that you define. A destination is an HRMS role, or a specific user linked to that role.
When routing by position hierarchy, the application determines the occupant of the next position in the position hierarchy, using the current user's position (primary assignment) as the starting point.
When routing by supervisory hierarchy, the application determines the current user's supervisor (the supervisor listed on the user's primary assignment) and routes to that person.
You can choose a different type of routing for each transaction type (position transaction, budget worksheet, budget realloction transaction). The application routes all transactions that belong to a given transaction type the same way. For example, if you choose routing list as the routing style for the budget worksheet transaction type, the application routes all budget worksheets using routing lists.
If you decide to change the routing style later, you can make that change after the application updates any pending transactions. The Transaction Status window shows you which transactions are pending.
You can accommodate the different approval schemes in your organization by defining multiple routing types, such as several routing lists, and then defining routing and approval rules that instruct the application on what basis to select a routing list or an approver.
When a user initiates a transaction, such as a budget worksheet, the application compares the values contained in the transaction with the routing and approval rules to determine which user can next receive and/or approve the transaction. The application performs this step at each routing destination.
For information about setting up workflow routing and approvals, see The Transaction Type Wizard
HRMS roles reflect the different types of responsibilities users perform in the routing sequence, such as Initiator, Reviewer, or Approver.
If you are setting up routing based on routing lists, you assign HRMS roles to users, specifying one role as each user's default role. When initiating transactions, the default role applies. Otherwise, when opening a routed transaction, the routing list role applies.
If you are setting up routing based on position hierarchy or supervisory hierarchy, the application looks for the role linked to the primary assignment position first. If not found, the default role applies.
You assign each HRMS role a role template, assigning the basic role template supplied with the product or one that you define. When initiating or opening a routed position transaction, the application automatically applies the role template.
The following table describes the HRMS roles applicable while initiating and opening a transaction:
Applicable Roles
| Action | Routing List | Position Hierarchy | Supervisor Hierarchy |
|---|---|---|---|
| When initiating a transaction | Default user role | Role linked to position | Primary position first. If not found, default role. |
| When opening a transaction | Routing list role | Role linked to position | Primary position first. If not found, default role. |
You can assign HRMS roles as global or business group roles. Business group roles apply to only one business group, while global roles enable HRMS roles to extend into all business groups. A user assigned to a global role may view, approve, or forward transactions created in another business group. Those assigned to business group roles can view and act upon transactions only within their own business group.
Note: You can use global roles with routing lists and supervisory hierarchies, but not with position hierarchies.
During the routing process, you have a choice of actions that you can take on the transaction:
Save and Continue - Saves the transaction information while you continue working on it
Save - Saves and stores the transaction in your inbox
Forward - Sends the transaction to another user for further action
Send Back - Returns the transaction to a previous destination
Reject - Sends the transaction back to the initiator, who can then close it
Any recipient (initiator, reviewer, approver) can reject a transaction. Rejected transactions go back to the initiator, but the Send Back option routes the transaction to any previous destination you specify.
Override Approver - Sends the notification directly to a user previously designated as override approver for approval.
At any point in the routing sequence, you can expedite the approval process by routing the transaction directly to the override approver.
The application automatically determines the next destination on the routing sequence. However, you can skip a destination and send the transaction to someone else in the routing sequence.
You can also make sure that the transaction does not sit in someone's inbox unattended by setting a response time (in days). If the interval elapses with no response, the application returns the transaction to the initiator.
During the routing process, you can choose to notify yourself or other users when a specific event occurs, such as a successful update to the database. You can also have the notification sent to someone else in the routing sequence. For example, when the application updates a future-effective position, you can have a notification sent to a manager to alert the manager that the position is now updated and available.
The application stores a history of all the actions taken in routing a transaction in the Transaction Status window. You can view the routing history to determine the chain of events--what action a user took and when, as well as prior and subsequent routing destinations.
The first approver who receives the transaction can approve and apply it to the HR database. For example, in a position hierarchy several positions might be listed as approvers, but the first approver on the routing sequence to receive the transaction can approve it. When a position has multiple incumbents, the first incumbent to act on the transaction does so on behalf of all incumbents of the position.
The person who updates the transaction does not have to be an approver. The approver can forward the notification to someone else for update to the database.
You can apply and post transactions immediately or later. If you are updating current and retroactive actions, immediate posting updates the data as soon as you submit it, but you may have to suspend work for a moment while the update is performed. Posting later frees you to continue working while the Background Workflow Engine performs the update.