Integrating Student Data into PeopleSoft Campus Solutions - A Practical Guide

The article provides guidance on how to think about integrating with PeopleSoft Campus Solutions (CS) to create students. It covers the functional and technical considerations for creating a student inside Campus Solutions. This will hopefully be educational for software providers looking to integrate with PeopleSoft Campus Solutions, as well as staff at universities. The article is more of a deep dive into the functional side of Campus Solutions. The chapter Strategies to Integrate with PeopleSoft gives you some understanding of the high-level technical approaches. We will touch on some high-level technical details but not go too deep.

The author has extensive experience creating custom PeopleSoft integrations, including admission and application systems, student success systems and dashboards, CRM systems, non-credit shopping cart systems, and data syncs to external systems.

While PeopleSoft offers some special-use-case web services for CS integrations, custom integrations are preferred for flexibility, in my opinion, and based on extensive real-world experience. That is the “lens” that this article is written in. You can read about my opinions on this in my article The Pros and Cons of PeopleSoft Bolt-ons versus Customizations.

Overview

First, let’s describe a scenario that I have seen many times for a university admission flow into PeopleSoft. There is no one “right” way to get students into PeopleSoft, and each university will have different steps depending on business, policy, and technical reasons. However, there are many common things that must occur, which we will discuss in detail below.

• If the university is highly selective, like an Ivy League school, then there will be vetting, interviews, and a selection process that may take months. That review may take place in systems outside PeopleSoft CS since CS does not have an effective mechanism for this business process. Generally, “final” or “qualified” applicants may get pushed into PeopleSoft as applications (much more on this later). After those applicants have accepted admission, they get matriculated and become real students.
• If we take the opposite extreme and look at non-selective schools, like a community college, almost every applicant gets moved into “active status” without admissions department review.
• If you are integrating a non-credit shopping cart system, every student needs to be pushed to PeopleSoft because they have paid for some non-credit class, and PeopleSoft needs to be in sync, and there is no review process.

Every school executes this business flow differently, and often schools are receiving applicants and leads from various places like lead generation companies, marketing efforts, pay-per-click advertising, or custom self-service applications. There are many CRM and Applicant tracking systems on the market that are SAAS applications, and many vendors and schools have created bespoke solutions for their specific use cases. Most of those applications are “top of the funnel” application used to manage the influx of inquiries, and they are used to organize outreach and vetting efforts. Once the admissions department is ready to admit a student, that is where the PeopleSoft integration comes in.

The general flow is to:

1. Capture inquiries or external applications from various sources.
2. Consolidate inquiries and applicants into a CRM or applicant tracking system.
3. Interview the candidate and eventually offer some subset of students admissions. This step varies widely between selective and non-select universities as well as graduate and undergraduate admissions.
4. For candidates that accept the offer then you admit the students into the SIS.

In this article, we are not going to address all the external systems and the reviews. We are going to focus on how to actually create applicants and active students in PeopleSoft and what transactions need to occur inside PeopleSoft Campus Solutions. So we are really discussing here the “bottom of the funnel”.

We will go over each of the steps in the sections below. Here is a schematic of the flow of those steps.

Search Match

The first step in integrating applicant and student data is a “search match.” This is an extremely important step that is done prior to creating any person in a PeopleSoft HR or Campus system. This involves using the personal data that came in on the application and searching against existing records in PeopleSoft. Schools do NOT want duplicate people created in their system. In PeopleSoft there is NOT a way to merge duplicate student records. It is manual, tedious and may require hours of work across departments to correct one duplicate student. So it is important to prevent duplicate at the front-end of the process. This is a major concern of Universities. ✨

Search Match is just the act of taking the inbound data from the application and running SQL against the database looking for potential matches. In a simple scenario where all record in PeopleSoft have an USA SSN and the application data includes an SSN then this can be easy. However, many schools cannot ask for SSN (or other National ID) for various reasons or they may not store it in the database. I have also seen situations where the search match must include archived data or databases outside PeopleSoft because of legacy system storage.

Every school has developed their own unique search rules and there is no single “correct” way to do this. What parameters are used to search for a matching person is different at each school. It depends on what data is accepted on the application and the level of confidence there is with the data. Generally, there is a search on the following fields in various combinations:

• Names
  • There are often different combinations of partial names searches.
• Date of Birth
• SSN
• Emails
• Addresses
• National ID numbers

If potential matches are found in the system, then a manual human intervention is required to determine if it is truly a match or just a similar person. For example, a match could come up for a common name and birthday but the SSN differs (twins?). Alternatively, there could be an SSN only match which could be a typo on an existing student or a typo in the application data. In this case, the admission department will be looking for some validation of each person to determine who really owns that SSN/National ID. For large institutions, millions of prior students, employees and applicants may exist and there is a strong desire to keep the same ID (PeopleSoft Field EMPLID) especially if the person is a previous student with previous academic history.

The way PeopleSoft is structured you have one person record with a single ID (EMPLID) then you can have any sort of relationship with the university (Student, Contractor, Employee, Alumni, etc.). There is always a desire to re-use the same EMPLID if the person had any sort of relationship with the university.

• Does PeopleSoft deliver a web service? No

Some things to consider.

• Data security - Not all users should be able to see information on people. For example, there may be employee National ID numbers stored for employees that staff member should not see.
• There could be information returned in blocks and service indicators that certain staff members should not see. For example, some admission staff may not be allowed to see that the person is in collections with the university. This is very specific to the operations of the University.

Here are some screenshots of the search match screens. There are a few ways to trigger this and we are only including one here.

The first is a search where no results are returned.

Here is a second search that returned some results (this is fake data)

Here are the resulting matches and you can see what rule found the match. The use click’s “carry” to copy the matched ID to a sort of “clip-board” which can be used in other PeopleSoft pages to update that ID. If none of these are a match then the user moves on.

Blocks and Negative Service Indicators on Search Match Results

If your search match returned a match that you want to update, there are often some additional checks to determine if this person should be allowed back at the institution. This is very University specific.

• Where they a prior student who owes the university money?
• Where they dismissed for Academic Dishonesty or some sort of negative behavior.
• Was the person a past employee that was dismissed on unfavorable terms?
• Does there record have some sort of identity theft flag?

These are stored in PeopleSoft on various ways. The most common way theses are flagged in Campus solutions is through “Negative Service Indicators.”

If any of these blocks are found then that might put the applicant into some special flow to deny them and close out their application process.

There is not any real ways to surface these other than manually looking for them on the PeopleSoft pages. Generally, Service Indicators are used and we cover those below.

Create or Update Person

The next step is to create or update a “Person” in PeopleSoft. If the search match resulted in no matches then it will be a created. If the search match returned a match, then you may be updating an existing person and appending some data.

The PeopleSoft navigation for this is:

• Campus Community → Personal Information → Add Update a Person

The inputs you need for this are:

• Names
• National IDs
• Personal Indicators
• Addresses
• Date of Birth
• Phone Numbers

What are some key things to think about here:

• For Person Updates:

  • Do you update SSN if it differs from what is in PeopleSoft?
  • Do you update DOB if it differs from what is in PeopleSoft?
  • Do you have preferred name?
  • Do you replace all email addresses and phone numbers or keep some intact and the person can update their own information in self-service after they get an account?

• For Creates:

  • What fields are required? Are there fields missing in the application that are required in PeopleSoft or policy? For example, many schools may not ask for National ID which is problematic for search match but may need it after admissions. At what point does it get entered?

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? YES

  • Component Interface: HCR_PERSONAL_DATA_SRV
  • Component: SCC_BIO_DEMO

• Key PeopleSoft Tables

  • PERSON
    • NAMES
    • PERS_DATA_EFFDT
    • EMAIL_ADDRESSES
    • PERSONAL_PHONE
    • ADDRESSES
    • PERS_NID
    • ETHNICITY

Here are screenshots of the component where this data is updated.

Application Data

Campus Solutions has functionality to track “applicants” throughout the admission cycle. However, it is not well-designed and I have not seen many schools make impactful use of it. Some schools require that all students have some data entered into these tables for various reasons. There is no requirement in PeopleSoft to put any data in these tables to create an active student, so this could very well be skipped.

These “application tables” are prefixed with “ADM_” for their table names. They are meant for storing people who are interested in attending the University but need to be reviewed and tracked prior to admission (if they are admitted at all). This might be for students who are applying to a selective or limited degree (program and plan) or to a very selective school.

• These tables are keyed by EMPLID (person ID or student ID), so prior to storing data in these tables, a search match must have been done. This is often a major showstopper for storing inquiries as we will see below.
  • So what I have found in practice is that these tables are often used for “final applicants” that have been vetted and are likely to be admitted. Or these tables are populated for some later reporting after admissions.
• I have found that, generally, you cannot trust data coming in on applications. Here, I am speaking to applications that are coming in for web forms or general inquiries. These sorts of inquiries are generally stored in some form of “lead tracking” system like Salesforce or other CRMs. You do NOT want to take that data and create “persons” and applications because there is often all sorts of junk data and duplicate data coming into those forms.
• There are certain applications like “Common App” or state level applications that do send in quality application data. In those cases, these tables could be used to track the “status flow” of an application from inquire -> admit with certain “action” codes. I have not seen many schools use this for many nuanced reasons. There is NO requirement that these be set in PeopleSoft to admit a student. I have found that some schools do it for downstream systems or reporting purposes, and they have “just always done it that way”.

These tables are geared around tracking what degrees (program, plans and sub-plans) the person is applying for. So the data here needs to be specific to the institution PeopleSoft data which is not always convenient for some application processes because the student may not know what they want to apply for early on. Again this is very specific to the type of university this is. Selective, Non-Selective, Undergraduate, Graduate and non-credit will have very different things to consider.

• Student Admissions → App Entry → Add Application

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component Interface: N/A
  • Component: ADM_APPL_ENTRY1
  • Component: ADM_APPL_MAINTNCE

• Key PeopleSoft Tables

  • ADM_APPL_DATA
    • ADM_APPL_DEP
    • ADM_APPL_PROG
      • ADM_APPL_PLAN
        • ADM_APPL_SBPLAN
      • ADM_APP_CAR_SEQ

Here are some screenshots of the PeopleSoft pages.

What are some key things to think about here:

• Do you need to track application data in PeopleSoft? What do you gain from this?
• Do you really want to push data into these tables for general inquiries?

Activation or Matriculation

In this step is where you establish a relationship between a student ID (EMPLID) and academic data. When admitting a student, this is the first step to tell the system that they are active in some program, plan and optionally a sub-plan. PeopleSoft experts call this the “program plan stack.” As a student progresses through their journey they will get several rows added to this table over time to show the different “action” and “reason” codes that they have taken from first admission, transcripts reviewed and graduation or dismissal or withdraw. There is information in these tables that tell the system what degree the person is seeking and what catalog year they are bound to.

There are other features of the design of this table where a student can have more than one “career” (ACAD_CAREER) and could be seeking degrees at more than one college or institution. There are layers and layers of nuance to this table and every PeopleSoft schools uses these tables in different ways and expect certain data entry to occur in specific ways. For example, there is a field called “STDNT_CAR_NBR” (Career Number) that is used very differently between schools. It allows some segmentation between different career paths when tracking the student history. For example, if a student left the university and came back. I have seen situations where the school wanted to use the same career number in that situation and others that wanted to always create a new career number.

Any data integration into this table will require detailed discussion with the Student Records department on how to key data. For existing or past students, there are many aspects to consider.

PeopleSoft Navigation:

• Records and Enrollment → Career and Program Information → Student Program / Plan

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component Interface: N/A
  • Component: ACAD_PLAN

• Key PeopleSoft Tables

  • STDNT_CAREER
    • ACAD_PROG
      • ACAD_PLAN

What are some key things to think about here:

• How are re-admitted students handled? Do they get older catalog rights?
• What happens to students who have received a degree and or certificate and are coming back for a secondary degree.
• What happens when the student has an older active record that was never de-activated? How is this handled?
• What are the required actions and reason rows required here?
• Are there any downstream processes that key off this table that have certain assumptions about the data like effective dates or other fields?

Here are some screenshots of this page where we are basically doing a quick admit.

First the user must choose the “Career” (ACAD_CAREER). These are the delivered values and your schools will have a much more limited list.

Term Activation

This is a simple page and may not be a required step during admission processing from external system but is required to register in classes. This component in PeopleSoft tells the system what terms the student is active in and can register for classes in. There is a row for each active term. The technical structure here is by “ACAD_CAREER” which isi covered above. There are some term level statistics gathered on this table. A student cannot register for a class

• Records and Enrollment → Student Term Information → Term Activate a Student

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component: STDNT_ACTIVATION

• Key PeopleSoft Tables

  • STDNT_CAR_TERM

What are some key things to think about here:

• Is there other automation’s that may automatically term activate students based on some academic calendar?

Here are a few of the screenshots of two key pages. There are some other pages I am skipping over as they have very narrow use cases. There will be a row for each ACAD_CAREER and term combination here.

Residency Data

Generally, most schools track some sort of residency statuses. The data coming in from the application may just be self-declared or it could be validated by your admissions staff during the review process. In PeopleSoft, the inbound integrations will likely need to set this status if the inbound data has validated information. I have also seen where even non-validated data is set then there is some later business process to ask for proof of residency each term or yearly. This is very school specific.

• Campus Community → Personal Information → Identification → Residency Data

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component Interface: N/A
  • Component: RESIDENCY_PERS

• Key PeopleSoft Tables

  • RESIDENCY_OFF

Here is the first page of the residency page. You will notice that this is set by ACAD_CAREER.

Service Indicators

PeopleSoft Campus Solutions has a data element that you can attach to a person called “Service Indicators”. These are completely configurable and are used to flag students in both positive and negative ways. They are used all over the place to flag negative things like the person having a registration hold or owing money. They may also flag positive or special things like the person being the “Dean’s Son”. There is often overlap with student groups regarding this usage.

You see Service Indicators used all over the place because there are some icons on almost every student-facing page that will surface these service indicators, especially negative ones. That makes it an effective and central place to put holds, blocks, and other items that should flag the attention of staff.

When integrating with PeopleSoft to create student there may be a need to create service indicators for special types of applications.

There NOT a requirement to set any service indicator on students. However, there may be cases where it is important to flag students from certain systems, high school student’s attending college classes, students who have not attended an orientation session, and many other things that people have imagined in PeopleSoft. Again these are used on wildly different way across installations because they are so flexible.

• Campus Community → Service Indicators → Person → Manage Service Indicators

• Does PeopleSoft deliver a Component Interface? No

  • Component: SERVICE_IND_PERS

• Key PeopleSoft Tables

  • SRVC_IND_DATA

External IDs

PeopleSoft Campus Solutions has a delivered place to store external “IDs” from other systems for a given student ID (EMPLID). This is optional but you may want to store Lead IDs, Applicant IDs or some other reference against the student.

• Campus Community → Personal Information → Identification → External System ID

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component Interface: N/A
  • Component: EXT_SYS_ID_PERS

• Key PeopleSoft Tables

  • EXTERNAL_SYSTEM

Fee Payment

If there are application fees that were paid in external payment systems, a record of that can be reflected on the student account. The only entry point into the Student financial record is via the “quick post.” This is an ugly COBOL process and a bunch of horrid spaghetti code to integrate with. I have seen other instances where the school gives the applicant a self-service account, and they can make a payment using the payment provider integration with PeopleSoft. This is very school specific and for schools that have application fees I often see them collect way up front prior to any data being pushed to PeopleSoft.

• Fee Payment

  • Student Financials → Charges and Payments → Post Student Transaction
  • Self Service Payment via Payment Provider

• Do PeopleSoft deliver a web service? No

Equation Variables

This “Equation Variable” component comes with functionality that can be used by the student financials team to flag students in certain ways to manipulate the student financial calculation.

These equation variables are essentially client custom fields that enable the student financial team to waive fees or add fees for various reasons. Additionally, the variables allow for miscellaneous tasks within the financial realm. The system provides several open placeholder fields that student financial rules can be written against. When PeopleSoft calculates tuition, it looks at these student level flags called equation variables and can make determinations on how to calculate the tuition properly.

It is important to note that this tool is highly school specific, and may not be applicable to all institutions. However, for those who do utilize PeopleSoft, it can be an incredibly helpful tool for managing student financials. By allowing for the manipulation of fees and other financial tasks, it provides a level of customization and flexibility that can benefit both the institution.

• Student Financials → Tuition and Fees → Equation Variables

  • Destiny One will not set any values here.

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component: STDNT_EQUTN_VARS

• Key PeopleSoft Tables

  • STDNT_EQUTN_VAR

Student Groups

Student groups are categories or groupings that schools can use in various ways to better support their students. These groups are set on the student. These groups are school-specific and can be used for a variety of purposes, from tracking academic progress to identifying and providing additional support for students who may be facing challenges.

It is important to note that there is no requirement to set student groups during the admissions process. However, some schools may choose to use this tool to flag students who are in certain statuses or come from certain sources. For example, community colleges may create student groups for students who are concurrently enrolled in high schools to better support their unique needs.

Additionally, student groups can be used to identify students who are part of sports teams or other extracurricular activities. This can help schools provide additional resources and support for these students.

Records and Enrollment → Career and Program Information → Student Groups

• Do PeopleSoft deliver a web service? No

• Does PeopleSoft deliver a Component Interface? No

  • Component: STDNT_GROUPS_PERS

• Key PeopleSoft Tables

  • STDNT_GRPS
    • STDNT_GRPS_HIST

Security Profiles

Students generally need a PeopleSoft security account (OPRID) to be able to access self-service functionality. The process for creating these accounts can vary depending on the school’s admissions process. In highly selective universities, self-service applications may be created for students at the applicant level, allowing them to review their status, upload documents, and even accept admissions and pay fees. In these cases, a security account must be granted to the applicant in order for them to access these features.

On the other hand, in non-selective organizations, self-service accounts are generally only created once the student is matriculated. This could be a requirement for the admissions’ integration code or an automated process that looks for matriculated students and creates accounts for them. The exact process can vary greatly depending on the school.

While the process for creating PeopleSoft security accounts may differ, it is an important step in getting students on-boarded into the system. It provides a secure way for students to access their information and perform necessary tasks, while also allowing the school to manage and control access to sensitive data.

• Security Profiles

  • PeopleTools → Security → User Profiles → User Profiles

• Do PeopleSoft deliver a web service? Partially via “Enrollment Web Services”

Class Registration

After all the required steps listed above are completed then class registration can happen. This could potentially be something that needs to be automated. For example, there may be some sort of orientation class that gets automatically added to the student’s schedule or other college training class.

Alternatively, it could be that all classes are added by the student. If integrating a non-credit shopping cart system, then you may need to push these integrations thought.

Custom Tables and Downstream Processes

When it comes to implementing a new system for a school, there are often many factors that must be taken into account. One of these factors is the possibility of custom tables within the PeopleSoft system that the school may have created. These tables could contain additional fields not supported by PeopleSoft, such as county level data, high school specific codes, government level codes, or specific values for ethnicities that were not available in PeopleSoft delivered functionality.

In addition, certain military codes and flags may need to be set in a special way, and each school will have their own unique fields. Therefore, it is impossible to provide specific examples without understanding the individual school’s needs. We just want to mention this as an item to consider in the integration design.

Another important aspect to consider is the downstream processes that are often tied to new student matriculation. This could include the creation of students in various systems such as SSO systems, learning management systems, or PeopleSoft bolt-ons. It is crucial that the data is written in the system correctly to ensure that these downstream impacts are handled properly and triggered as needed.

As we can see, the implementation of a new system is not a one-size-fits-all solution. Each school will have its own unique needs that must be taken into consideration. By understanding these needs and properly addressing them, we can ensure a successful implementation that will benefit both the school and its students.