I then routed the digitized versions of those transcripts through ImageNow for subsequent processing needs, such as coordinating with OOTR’s transcript collections team to troubleshoot incomplete transcripts and send foreign transcripts to translation agencies. Through a process of exploration, trial and error, and refinement early on in my position, I created my “tablemat cheat sheet” Excel spreadsheet. This spreadsheet shows my personal decision making process in light of both admissions policy and internal OOTR student record organization, describing step by step how the evaluation of a transcript dictates how its relevant information is logged and saved to a student record, in a process conceptually akin to document indexing in a traditional academic database. The ways in how transcripts are linked to student records influence how such records are retrieved when students, the university’s admissions representatives, and co-workers request OOTR services. [Side note: Admissions representatives in this particular context liaise directly with prospective students, who may be graduating from high school, transferring in from another college or university, or seeking master degree program options. In this regard, OOTR works directly with the transcripts that students submit to fulfill their admissions applications, making admissions representatives one of my main client groups whom I interacted with on a near daily basis.]
Since the documents that were in OOTR’s HRM systems (PeopleSoft, SalesForce, and ImageNow) were student records, in terms of their profiles and stable, retrievable records of document relationships (which involve a student’s transcripts, scanned OOTR forms requesting various services, and other associated documents), my position were necessary to ensure that information was logged, linked and maintained properly for the purposes of student lookups. Part of my workflow in logging transcript information in student records involves being able to answer questions, troubleshoot transcript issues, and fulfill OOTR service requests from students, admissions representatives, and fellow OOTR co-workers. When fulfilling these requests, I retrieved student information using PeopleSoft and SalesForce through a process of searching for exact matches by student ID. If I had no student ID (which happened quite a lot, due to name changes, multiple profiles, alumni students forgetting their ID number, etc.), I conducted searches with partial demographic data such as last names, first names, date of birth, and the last four digits of a social security number. Such HRMs provide information for specific OOTR administrative purposes such as the duties that my supervisor held, from degree conferrals for graduation, change of academic major, academic probation, etc. In some respect, student lookups rely on many of the same principles of access and retrieval in document-centric databases.
In addition to the information that I logged about student transcripts, admissions representatives log information in SalesForce that are not present in PeopleSoft, adding another layer of information to a student’s whole record (and its associate metadata usable in SalesForce reports generation that summarizes a subset of student data for various internal organizational purposes not part of my roles and workflows). Even though the university’s IT department developed SalesForce as an external shell to display PeopleSoft content, it was still necessary for me in my position to navigate through both systems to retrieve relevant information about students in relation to their transcripts and potential system holds such as academic probations, financial holds, and FERPA (Family Educational Rights and Privacy Act) blocks. (FERPA only authorizes students to request and view their own academic information; third parties such as family and employers must provide specific paperwork to request authorization from the student and the school to see a student’s academic information.) I had to shift through this information at times when there were situations such as incomplete information on submitted transcripts (missing critical information like high school graduation dates, bachelor’s degree conferral dates, and academic coursework history). SalesForce also included student interactions with admissions representatives (e.g., calls, emails, program inquiries). In one sense, a student’s whole record was fractured across two different records in two different IR systems; in another sense, this organization system protects aspects of a student’s whole record, allowing only specific employees such as myself to access another level of information not easily available to other employees, namely the student’s digitized transcripts. And all this information is accessible by the same key, the student’s ID number.