9.2 Offboarding - Security Procedure

Purpose:  Use this document as a reference to ensure that an offboarding employee is not active at another institution, and to adjust the employee's roles, SACR and User Preference Definition settings.

Audience:  Local Security Administrators

You must have at least one of these local college managed security roles:


If you need assistance with the above security roles, please contact your local college supervisor or IT Admin to request role access.

Offboarding - Security Procedure

When an employee offboards from an institution, it is critical to clean up their security access within the system.  It is very important to ensure that the employee is not active at another institution.  Since there is only one User ID in the system for an active employee, it is critical to coordinate with other institutions if the employee transferred and is active.

It is critical to login to the HCM Pillar and run the query named:  QHC_SEC_HR_STATUS_SYSTEM_LEVEL

This query is meant to serve as a secondary tool to help identify inactive employees, vs employees that are still active somewhere in the system.  As a security administrator it is important that you also check with your HR counterpart and the HR counterpart at the other institution to confirm employment.

  1. It is critical to log in to the HCM Pillar and run the query named:  QHC_SEC_HR_STATUS_SYSTEM_LEVEL
  2. There is a procedure document for this query named 9.2 Employee HR Status System-wide.  Please refer to it to decipher the fields and data returned, but the most important two columns are:
    1. Employee Associated Companies column will list any companies that the user has ever been associated with. This doesn’t reflect active/inactive status, just association over time.
    2. System Status will display ACTIVE IN SYSTEM if the person is Active (at one or more institutions across the system), and Inactive in System means that they are not active at any institution in the system.  The next two columns will show HR Active Company and HR Inactive Companies.  If the person is not active at any company the security administrator should clean up the roles/secondary security within each pillar.  If the person is inactive at their institution but active at another, the security administrator should contact the security administrator at the active college and work together to clean up the security for the employee.  From an audit perspective, it is important that the security administrator at the institution the person is leaving, removes any roles (above base employee roles) that they manually added.  The new institution’s security administrator would then Add back any roles that the person needs to do their job there.  There is a record in Query called AUDIT_PSROLEUSER.  This record will show who added/deleted roles from a user.  When auditors look at the data for terminated employees, they will be looking to see if the admin at the campus the person terminated performed offboarding.  Therefore, it is critical that the roles are removed by that campus.  There can be timing issues, especially if HR doesn’t enter the termination data in a timely manner.  We will be updating the Onboarding document as well for this procedure.  It is a two part effort and has to be coordinated between the colleges. 
  3. Example:  Person Terminates from College A and goes to College B
    1. Steps:
      1. College A should run the system status query to see the person went to College B;
      2. College A’s local security admin should contact College B’s local security admin and setup a time for offboarding.  College A will need to remove any role above base employee access that they assigned to the user, even if the user needs it at college B.
      3. Then College B can onboard the employee for their institution so that from an audit perspective it is clear they were Offboarded and Onboarded Properly.
      4. Since sometimes there is a timing issue, when onboarding a new hire, it is critical that colleges still run the QHC_SEC_HR_STATUS_SYSTEM_LEVEL query to see if the person was at another institution.  They should reach out to the prior institution to repeat the above steps prior to onboarding so that the users access is clean.
      5. Once it is confirmed that the employee is no longer active at any institution, follow the below procedures for offboarding by pillar.  If they are active at other institutions, you will still need to clean up things like SACR, User preferences etc and coordinate with the other colleges on role removals.  See below sections for that as well.
      6. The query QXX_SEC_USER_ROLES_NOT_LOCAL should be run in all pillars to show what roles the user has that are NOT on the local role grant list.  A ticket should be opened to SBCTC for the security team there to remove these roles for you upon termination.  The ticket should contain the appropriate approvals.
HCM Pillar

Regarding Returning Employees

The Local Security Administrator must add the ZZ PeopleSoft User role manually if the person is not new to the system, but is returning as an employee.  

When a brand new user profile is created in ctcLink, by default the employee will have the base roles assigned, including the ZZ PeopleSoft User role.

If the employee already existed in the system then left, the ZZ PeopleSoft User role would have been removed as part of Offboarding, When the employee returns to active employment, the role will need to be manually assigned by the Local Security Administrator.

  1. When offboarding an employee, the security role of ZZ PeopleSoft User will need to be removed manually by the Local Security Administrator. The security role of ZZ Former Employee will be added dynamically. It is important to make sure the following roles are attached to a former employee so the employee can still access tax information, update their personal details, view old paychecks, etc.
    1. EOPP_USER
    2. PAPP_USER
    3. NA Payroll WH Form User
    4. CTC_%_DISTR (Dynamic)
    5. ZZ FORMER EMPLOYEE (Dynamic)
  2. HCM is pretty straight forward as there are no secondary security setups.
Finance Pillar
  1. Once HCM pillar is updated, then roles will update in Finance.  The ZZ PeopleSoft User role will automatically be removed and the ZZ Former Employee role will sync to Financials.  There should be no need for a former employee to access Financials, unless they have an outstanding Cash Advance or expense report, in which case they could work with the Expenses Administrator on their campus to finalize those transactions on behalf of the employee.  If the user is active at another institution, please check all workflow type roles and remove your institution route controls from them, as they would still receive workflow transactions if this is not cleared.   In Financials, the only roles that should remain are:
    1. EOPP_USER
    2. PAPP_USER
    5. (CTC_%_DISTR) can be there; this is optional as it only controls Tile access in Portal to your institution.  They will retain it in HCM, however there is no harm in keeping it in Finance.

Finance has secondary security considerations.

Navigation to User Preferences:  NavBar > Navigator > Setup Financials Supply Chain > Common Definitions > User Preferences > Define User Preferences

Roles: ZD Local Security Admin

  1. It is a good idea to go through user preferences and remove your institution specific Business Unit especially on the overall preferences link.  There is a report Set Up Financials/Supply Chain > Common Definitions > User Preferences > User Preferences Report that you can run to display any user preferences by user id.  Ensure you select All Products and enter the user id of the terminated user.
  2. If the terminated user was a Buyer or Requester go to the Procurement link under user preferences and select Requisition Authorization and Purchase Order Authorization and remove their user id from there, or unselect full authority.  However, it is not advised to inactivate their requester/buyer setup under Setup Financials Supply Chain >Product Related > Procurement Options > Purchasing > Requester Setup or Buyer Setup; IF the user has in process transactions, inactivating them here could cause issues processing the requisitions or purchase orders.

Department and Project Chartfield Managers:  NavBar > Navigator > Setup Financials Supply Chain > Common Definitions > Design Chartfields > Define Values > Chartfield Values

Roles: ZD GL Local Config Inquiry, ZZ GL Local Configuration

  1. If the terminated user was a manager on a project or department, the chartfield needs to be updated with the new Employee id of the replacement; This is critical for some of the workflow routings.

**If you are not entering a new effective date, you will need correct history and only the Central SBCTC team has access to correct history, so a ticket will be needed to coordinate the manager update on the chartfields.

Treasury Security:  NavBar > Navigator > Financials Gateway > Security > Security User Assignment

Roles: ZD Treasury Local Config Inq, ZZ Treasury Local Config

  1. If the terminated user had Treasury access go here and remove the payment security rules.

Commitment Control Budget Rules: NavBar > Navigator > Commitment Control > Define Budget Security > Assign Rule to User id

Roles: ZD CC Local Config Inq, ZZ CC Local Config

  1. If a user had the ability to override a budget date or exception then you will need to remove the budget security rules from them upon terminated.

Expenses Approvers: NavBar > Navigator > Setup Financials/Supply Chain > Product Related >Expenses > Management > Approval Setup > Approver Assignment

Roles: ZD Expenses Local Config, ZZ Expenses Local Config

  1. If the terminated employee was an expenses approver, navigate to the above and replace their user id with the user id of the replacement.
  2. If you use Delegates in Expenses under Travel and Expenses > Manage Expenses Security > Authorize Expense Users, and this person was a delegate for someone, this needs to be updated as well.
Campus Solutions Pillar
  1. There is no real need for a terminated employee to have Access to Campus Solutions upon Termination.  Therefore, all roles could be removed.  However, the administrator must ensure that the employee is not a current or former student.  If they are or have been a student they will need to retain the ZZ PeopleSoft User role and the CTC_%_CC role for the college as well as the ZZ SS Student, EOPP_USER and PAPP_USER roles.  Student access is controlled dynamically by the processes that run in the background that assign the ZZ SS Student role. This role is never removed by the LSA, as it is controlled by the system based on the student's engagement at their various institutions.
  2. Faculty, whether full or part time, their ZZ SS Faculty and ZZ SS Advisor roles are assigned dynamically by the existence of an 'active' record for your institution on the Instructor/Advisor table. LSAs would not manually remove these roles as the system will only remove these roles if ALL instructor/advisor entries are inactive for all colleges.  If a Faculty is no longer active at your institution, it is recommended to inactivate them on the instructor advisor table.
  3. SACR Values should be cleared for your institution if they are not a student there:  NavBar > Navigator > Setup SACR > Security > Secure Student Administration > User ID, Roles: ZD Local Security Admin, ZZ Local SACR Security Admin
  4. Clear all institution values from here for your college:  NavBar > Navigator > Setup SACR > Security > Secure Student Financials > User ID, Roles: ZD Local Security Admin, ZZ Local SACR Security Admin
  5. If you add a user to the Access Control tab of the Note Category Table, upon termination this needs to be removed:  NavBar > Navigator > Setup SACR > Product Related > Academic Advisement > Note Category Table, Roles: ZC SACR AA Config, ZD CS ADVISEMENT SETUP, ZD SACR Advisement Config
  6. If the employee is not a student and not active at another college you could use the User Security Replacement tool, to pull up the employee and copy from a userid that doesn’t have ANY SACR values to wipe it out.
  7. There is a BI Publisher Report that can be run to identify SACR for an individual: BCS_SEC_SARC ;  Run this to identify what SACR a person has.
  1. Process complete.


Add your comment

E-Mail me when someone replies to this comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.