Fayetteville Policies and Procedures 330.1
Transaction Approval
Overview
The University requires formal approval for all financial transactions to ensure the responsible use of institutional resources, promote transparency and accountability, and comply with applicable laws, regulations, and internal policies. By defining clear authorization standards, the university enhances fiscal oversight, supports informed decision-making, and sustains public confidence in its financial operations.
Purpose
The purpose of this policy is to:
- Ensure accurate and timely managerial review
- Mitigate risks such as budget overages, inappropriate or illegal spending and fraud
Functional Approach
The University of Arkansas utilizes the Workday ERP system to initiate and route transactions for approval. This system employs role-based access control to ensure that only authorized individuals can approve transactions, and conditional routing to guarantee that the appropriate personnel are involved in the approval process.
Together, these mechanisms provide a robust and secure framework for financial oversight and accountability.
Transactions are created by Business Processes, which have workflow maps that move the transactions from initiation through all appropriate review steps (swimlanes). The individual Business Process workflows are created and maintained by the Workday Support Services team at the UA System level, in consultation with the UA institutions’ subject matter experts. The configuration of the Business Processes addresses various validations and materiality thresholds, when appropriate, as well as the specific roles associated with particular Organizations, including Cost Center, Supervisory Organization, Project, Grant, Gift, and Agency. A list of the current materiality thresholds (set by the impact of an entire transaction, not by individual line items) are appended to this policy. Other validations impacting the review swimlanes include the transaction type and resulting documents (such as Requisitions and Purchase Orders), which will add Finance and Administration reviewers. The review of a Business Process, therefore, is fluidly changed by the parameters of the Business Process configuration at the time of the creation of the transaction, with some roles noted by the system as Not Required (and, thus, omitted from the approval process for that transaction) and others noted as Required. Required swimlanes may substitute one role vs another, based on the criteria in the Business Process configuration. Additionally, some Business Processes allow reviewers to add a reviewer within an in-flight transaction. If a single individual holds multiple roles which participate in a transaction’s review process, the configuration allows for the transaction to be presented to that person once, for all pertinent swimlanes.
Security Roles are generally assigned to Positions, with very few administrative roles assigned to specific users. The individuals holding Positions with Security Roles can act in Workday based on the security access groups (Security Domains) governing the access of the specific Security Roles – including the ability to view, initiate, edit, delete, or review a transaction – as well as the applicable Organizations within the institution they can act on.
The Security Partners of the institutions are responsible for assigning Security Roles. The Request of Security Roles assures the Security Partners that the appropriate individuals are aware and approve of the Request, which routes to the Manager and/or Cost Center Hierarchy Budget Officer of the position before routing to the Security Partner inbox, but the Security Partners can also reach out to others as deemed necessary to ensure appropriate Security Role assignments. Also, Security Roles held by Positions are to be reviewed annually by the Managers of those positions.
Separation of duties is dually managed by the Business Process configuration and the review of Security Partners when assigning roles. Workday configuration requires a minimum of two
Each individual reviewer approves, denies, or sends back transactions based on their area of expertise and purpose their Security Role has on the Business Process. Once fully approved, Workday transactions have been reviewed by appropriate personnel for completeness, accuracy, and compliance – from Budget and fiscal responsibility to external reporting, University policy requirements, and applicable local, state, and federal regulations.
If a review swimlane invokes a role which is not assigned to a Position (or the Position is vacant), the system will route the transaction to Unassigned. Business Process Partners (a role held by Security Partners) can Reassign those transactions to appropriate individuals, as well as correct the underlying lack of role assignment.
Generally, the roles are vacant because of attrition, transfer, promotion, etc. However, some roles which are not assigned for our institution are invoked by Business Processes which are tenant wide. In those cases, the Business Process Partners move the transaction to the next swimlane by either approving as the Business Process Partner on that swimlane or by Reassigning the transaction to the appropriate holder of the role in the next swimlane. In either circumstance, the reason for the action is documented on the transaction.
If a reviewer is unavailable, a Delegation may be created. The Delegation may be submitted by the employee or created on their behalf by the Security Partners. In addition to the validations built into the Delegation Business Process, UAF requested that Delegations route to the Security Partners for additional review. Delegations can only be set up for a maximum of 90 days and can be set up for one Business Process, a combination of Business Processes, or all Inbox items.
All review activity on a transaction, as well as the assignment of Security Roles, is stored as historic data in Workday.
Revised December 15, 2025
Revised July 1, 2015
Reformatted for Web April 3, 2014
Revised August 18, 2010
Revised October 22, 2009
Revised January 3, 2008
Revised July 23, 2003
July 9, 2001
July 1, 2000