When to remove access
It is important to remove users’ access to Oracle Financials when they leave or no longer use the system. This is key to maintaining the security of the system. Additionally, leaving someone in a workflow once they have left can cause issues, for instance potentially leaving multiple projects without a person to approve expenditure and holding up related orders.
You may also need to remove access if someone's role changes.
You may need to remove all access or individual responsibilities.
Note: Removing access for staff transferring to another department
It is important to remove access when someone transfers to another department – that department’s authorised signatory for Oracle access should not request changes to access relevant to your department. Many people hold posts at more than one department so legitimately have access to multiple departments and therefore this is not challenged by the FSSC
Removing a user from the PO hierarchy will allow any approvals to either go to another individual in the same hierarchy position, or where the position is blank, to continue to flow up the hierarchy to the next filled position.
Tip: There is no need to delegate a position until a new user starts
Removing a user from the PO hierarchy will allow any approvals to either go to another individual in the same hierarchy position, or where the position is blank, to continue to flow up the hierarchy to the next filled position.
Removing access
To remove access, an online service request Remove Access to Financial Systems and Reporting Tools should be completed and approved by the department’s authorised signatory.
Note: we recommend submitting the online service request form at least a week prior to the user's leaving date. The Financial Systems Management (FSM) team will then apply a future 'end-date’ to the user’s account for the day immediately following their departure date.
There are three key scenarios to consider:
- Long term absence – access should be removed during long-term absence, such as long-term sickness, parental leave or secondments. Retraining is not required until access has been dormant for two years (note this has increased from 12 months).
- Transfers to another department – when transferring to a new department a user’s new access will not override their previous department’s access; the leaving department must ensure that the user’s access is removed and the new department can then request all appropriate Oracle Financials roles required for the user’s new job. Please see Manage Leavers for more information.
- GL Supervisors – when a GL Supervisor leaves, each of the users whose journals they approve will need their GL Supervisor updated. It is advisable to check the GL Hierarchy Report (available on the User Access Dashboard) to confirm if a user is a GL Supervisor and to identify which accounts need updating. Requests need to be submitted as FSM cannot make assumptions about changes that may be made to the GL Hierarchy.
- Project approval delegations – care needs to be taken where project approvals have been delegated to a PO hierarchy position which becomes vacant as this can lead to orders getting stuck with no one to approve. The User Access Dashboard can be used to identify any vacant positions with delegations so that these delegations can be amended, or the position filled by another user.
Additional checks
It is primarily the department’s responsibility for ensuring that users are removed. However, there are two back-up checks in place. While these catch exceptions, they should not be relied up as there can be a significant time delay when an account is at risk before it is identified through one of these checks.
- Closure of accounts after 100 days inactivity – an automatic process runs to close accounts which have not been accessed for 100 days on the basis that is accounts have not been accessed for this length of time the access is no longer required. If your access is removed but you do still require access, then please contact the Financial Systems Management Team. Note: This automatic process excludes Principal Investigators (PIs).
- Check against leavers – as Oracle Financials and CoreHR are separate systems limited checks against University leavers are undertaken. However these can be significantly in arrears of users' leaving dates.
