Overview: Approving Financial Transactions in Oracle – About Workflow

Most transactions generated in the Oracle Financial System must be approved by a person(s) with the appropriate financial authority before they are considered complete. Oracle uses workflow to manage the transaction approval process.

On this page:

To learn how financial authority is assigned at Stanford, see About Financial Authority @ Stanford.

 

Approval Authority

All University employees with a SUNet ID receive authority to access the Workflow module in Oracle through the responsibility "SU Workflow Notifications." Prior to receiving approval authority, approvers must:

Authorized approvers are expected to follow University policy when reviewing and approving financial transactions. Reference Policy Notes: Financial Authority and Policy Notes: Code of Conduct.

back to top

Oracle Workflow Notification System

The Workflow Notification module of Oracle provides a consolidated work list containing all transactions requiring approval action, regardless of the Oracle module they originated in. The first three items on an approver's worklist are listed at the top of the Oracle home page with one-click access to the "Full List". Using Oracle Workflow, approvers can:

  • Review notifications for transactions awaiting approval
  • Approve or reject transactions
  • View approval history and current routing lists

Email notifications signal approvers when a transaction is awaiting their approval.

back to top

Workflow Defined

Workflow is the automated process of electronically sending a transaction initiated in one of the Oracle Financial System modules to the correct person(s) for approval and in some cases FYI notification.

Workflow Participants

Generally, there are four potential participants in the workflow process for a given transaction:

  • The Originator initiates the transaction which starts the approval workflow process.
  • The Approver provides an official financial "OK" for the transaction, attesting that the transaction is necessary, correct, allowable, and allocable for the PTA, correctly coded and documented.
  • FYI Recipients receive an email notification informing them that the transaction has been initiated. FYI Recipients are not responsible for approving the transaction. For example, an FYI notification is automatically sent to the Labor Distribution Approver when a labor schedule change occurs. The FYI Recipient can follow up with the transaction originator as required.
  • An End-Route is added to certain transactions based on business rules. End-Route transactions route per the workflow to central office staff (i.e., Controller's Office, Procurement, Research Financial Compliance & Services or others) for additional review and approval. For example. iBudget journal entries will end-route to all Budget Officers responsible for the award-owning organizations.

Depending upon the type of transaction and the financial authority of the originator, workflow may begin and end with the originator, or it may route through any combination of the above participants before it is considered complete.

Workflow Routing

If authority is identical for two people on the approval routing list, the system will route to the first name it finds in the authority table. The best way to control the routing of transactions to approvers is to establish "unique" authority for each approver. For example, if you grant approval authority to three people at the same level (e.g., Project), you can assign them different dollar limits. The system will always choose the person with the lowest limit that will cover the transaction within a level. The person with the next higher limit will only be chosen when the first approver's dollar limit is exceeded.

Workflow Variations

Workflow differs slightly among the Oracle modules (iBudget, iJournal, iOU, iProcurement, Labor Distribution, and PCard). For specific details, refer to Workflow Variations by Oracle Transaction Type.

back to top

Oracle Authorized Approver Hierarchy

If the originator of a transaction does not have adequate financial authority to fully approve the transaction, it will be routed to an authorized approver for review and approval. The Oracle Financial System uses the account structure to identify authorized approvers. Email notifications are sent to the originator and approver(s) to confirm both the transaction initiation and the approver list.

Use the Oracle Signature Authority Query tool to search for authorized approvers by project, task, or by award. Reference How To: View Authority Assignments.

Expenditure Approver Hierarchy

For expenditure type transactions entered in iProcurement, iOU, PCard, and Labor Distribution, Oracle workflow starts looking for an approver at the specific task (Level 1 below) and then continues to subsequent levels as needed until it finds an authorized approver. If the system finds more than one authorized approver, it will route to the approver with the lowest dollar limit which is greater than the total dollar amount of the transaction.

Level 1 – The specific Project-Task combination
Level 2 – The parent Task, if one exists
Level 3 – The Project
Level 4 – All Tasks owned by a Principal Owner
Level 5 – The Task Owning Organization
Level 6 – The Parent Org of the Task Owning Organization

Revenue Journal and Fund Transfer Approval Hierarchy

For revenue journals and fund transfers, Oracle Workflow starts looking for an approver for the specific Fund (Level 1 below) and then continues to subsequent levels as needed until it finds an authorized approver.

Level 1 – The specific Fund (corresponding to the Award)
Level 2 - All Awards owned by a Principal Owner
Level 3 – The Award Owning Organization
Level 4 – The Parent Org of the Award Owning Organization

back to top