Updated KFS User Feed

Summary

Prior to March 2024 Kuali Financials was on-premise with a direct integrated feed to the LDAP directory service where it had access to any and all NetID accounts that were provisioned.  This data went back to at least 1996 and allowed KFS to resolve names, affiliations, department numbers, and other data necessary for operation of the financial system.   When Kuali Financials was moved to a SaaS cloud environment, the ITS team developed a new feed to provision users into KFS using the hrLoadJob.  The intent of this feed was to only send active users/employees/students into the system however the current functionality is missing several populations resulting in KFS being unable to resolve some data elements which impacts transaction, lookups, and other functionality.  While this current configuration does better to deprovision users from an active status to an inactive status, the net impact results in a lesser experience for end-users and additional activities for the ITS team.  As such the following requirements are being proposed for the development of a new user feed.

Filter for NetID Selection

Using LDAP select all NetIDs and their mapped attributes listed below where the NetID has either the attribute eduPersonAffiliation=member and/or eduPersonAffiliation=affiliate

Logic

By default we want Full Time Employees to be Active in the system (<Record> tag active property = true).   Students and Affiliates should be Inactive by default but included in the feed so their ID’s are generated but disabled.   If a student or affiliate has an active KFS Role or Group then their active flag should be sent with a value of “true” instead.

SQL to determine users in Roles or Groups

SELECT DISTINCT(MBR_ID), 'ACTIVE KFS ROLE' AS DESCRIPTION FROM kfs.KRIM_ROLE_MBR_T WHERE (ACTV_FRM_DT IS NULL OR ACTV_FRM_DT <= CURDATE() ) AND (ACTV_TO_DT IS NULL OR ACTV_TO_DT >= CURDATE() ) AND MBR_TYP_CD='P' AND MBR_ID NOT IN ('*','2','admin','kfsctmuser')

UNION ALL

SELECT DISTINCT(MBR_ID), 'ACTIVE KFS GROUP' AS DESCRIPTION FROM kfs.KRIM_GRP_MBR_T WHERE (ACTV_FRM_DT IS NULL OR ACTV_FRM_DT <= CURDATE() ) AND (ACTV_TO_DT IS NULL OR ACTV_TO_DT >= CURDATE() ) AND MBR_TYP_CD='P' AND MBR_ID NOT IN ('*','2','admin','kfsctmuser'); 

Mapping

Inclusion of the kfsctmuser

We have a user setup as a service account for running batch jobs in control-m.   That user is configured with the correct permissions to run batch jobs and must be included within each user feed.  This logic already exists in the current integration and is written to the end of the file before the final </hrmanifest> tag.

The kfsctmuser xml is:

<record entityId="kfsctmuser" principalId="kfsctmuser" principalName="kfsctmuser" active="true">

        <affiliationType>STAFF</affiliationType>

        <campus>01</campus>

        <employeeStatus>A</employeeStatus>

        <employeeType>P</employeeType>

        <baseSalaryAmount>0.0</baseSalaryAmount>

        <primaryDepartment>UC-1515</primaryDepartment>

        <employeeId>092001234</employeeId>

        <firstName>kfs</firstName>

        <lastName>ctmuser</lastName>

    </record>

Inclusion of StudentNetIDwork accounts:

There is logic in the existing user feed integration whereby netid’s contained in the UCONN_STUDENT_WORKER_T table on RPM_PROD read properties from the LDAP NetID Record and then generate XML in the user feed file for the StudentNetID work account.   While not in use currently this is desired and should be tested.   Because StudentNetIDwork accounts do not have all the properties that KFS requires, when the XML is generated for those records, it pulls the attributes off of the students regular netid account instead.   These include (dept #, employee id, etc.)

Sample XML Format

Header Tag
<?xml version="1.0" encoding="UTF-8"?>

<hrmanifest xmlns="https://github.com/KualiCo/ce-tech-docs/tree/master/v3_0 " schemaVersion="3" reportDate="2024-11-07T08:39:55.994-05:00" recordCount="18915">

Body

<record entityId="aab02005" principalId="aab02005" principalName="aab02005" active="true">

        <addressTypeCode>WRK</addressTypeCode>

        <addressLine1>UNIT 3093</addressLine1>

        <addressLine2>249 GLENBROOK RD.</addressLine2>

        <city>Storrs</city>

        <stateOrProvince>CT</stateOrProvince>

        <postalCode>06269-3093</postalCode>

        <country>US</country>

        <affiliationType>FCLTY</affiliationType>

        <campus>01</campus>

        <employeeStatus>A</employeeStatus>

        <employeeType>P</employeeType>

        <baseSalaryAmount>0.0</baseSalaryAmount>

        <primaryDepartment>UC-1216</primaryDepartment>

        <employeeId>475236</employeeId>

        <emailAddress>sandy.bell@uconn.edu</emailAddress>

        <firstName>Alexandra</firstName>

        <middleName>A</middleName>

        <lastName>Bell</lastName>

        <phoneNumber>860-486-0251</phoneNumber>

    </record>

<record entityId="btp98001" principalId="btp98001" principalName="btp98001" active="true">

        <addressTypeCode>WRK</addressTypeCode>

        <addressLine1>UNIT 1138</addressLine1>

        <addressLine2>25 GAMPEL SERVICE DRIVE</addressLine2>

        <city>Storrs</city>

        <stateOrProvince>CT</stateOrProvince>

        <postalCode>06269-1138</postalCode>

        <country>US</country>

        <affiliationType>STAFF</affiliationType>

        <campus>01</campus>

        <employeeStatus>A</employeeStatus>

        <employeeType>P</employeeType>

        <baseSalaryAmount>0.0</baseSalaryAmount>

        <primaryDepartment>UC-1515</primaryDepartment>

        <employeeId>037796</employeeId>

        <emailAddress>brett.paulson@uconn.edu</emailAddress>

        <firstName>Brett</firstName>

        <middleName>T</middleName>

        <lastName>Paulson</lastName>

        <phoneNumber>860-486-9364</phoneNumber>

    </record>

Footer Tag:

</hrmanifest>

Other Thoughts/Considerations:

Student employees – Also known as netidwork accounts.  We have some existing functionality in the  current user feed but have not yet taken advantage of it.  

Deprovisioning users – This is always an audit concern that we are deactivating users as close as possible to when they leave the University. – Possibly bolstered by SailPoint info.

Log-on role (role 1) – can this be leveraged to block users from logging in if they don’t have other access.   Impact to adhoc workflow etc.  – Likely do not need to go this route

Incomplete data in ldap – it happens.  Not sure the impact on the user feed.

Historical / back data – especially for payroll purposes.  We may need to do a 1-time load even after this new feed is established.

Impact of users being marked active/inactive – i.e. student users marked inactive but are present in the system.  Can the transactions function normally with inactive users?  – Looks okay for the most part.

Emeritus working and non-working will have the edupersonaffiliaton=member.  Probably okay as long as they have no roles.   Could always revisit and add the same logic for emeritus as students.