Integrating Student Data into PeopleSoft Campus Solutions - A Practical Guide

This 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. It 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.

I have 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” applications 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-selective 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.

Technical Quick Reference

The table below summarizes the delivered integration points and key technical artifacts for each step. As you can see, very few steps have delivered web services or component interfaces, which is why custom integrations are generally the preferred approach.

Step	Web Service?	Component Interface?	Component	Primary Tables
Search Match	No	No	--	Institutions specific but similar tables to Create Person
Create/Update Person	No	Yes	SCC_BIO_DEMO	PERSON, NAMES, PERS_DATA_EFFDT, PERS_NID, ADDRESSES, PHONES, EMAIL_ADDRESSES
Application Data	No	No	ADM_APPL_ENTRY1	ADM_APPL_DATA, ADM_APPL_PROG
Activation/Matriculation	No	No	ACAD_PLAN	STDNT_CAREER, ACAD_PROG, ACAD_PLAN
Term Activation	No	No	STDNT_ACTIVATION	STDNT_CAR_TERM
Residency Data	No	No	RESIDENCY_PERS	RESIDENCY_OFF
Service Indicators	No	No	SERVICE_IND_PERS	SRVC_IND_DATA
External IDs	No	No	EXT_SYS_ID_PERS	EXTERNAL_SYSTEM
Fee Payment	No	--	--	--
Equation Variables	No	No	STDNT_EQUTN_VARS	STDNT_EQUTN_VAR
Student Groups	No	No	STDNT_GROUPS_PERS	STDNT_GRPS
Security Profiles	Partial	--	--	--

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 duplicates 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 records 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 name 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 user clicks “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.

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

These are stored in PeopleSoft in various ways. The most common way these 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 are 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 a new person will be 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?

• Does 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

• Does 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

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

• Does 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 is covered above. There are some term level statistics gathered on this table. A student cannot register for a class without being term activated.

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

• Does 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:

• Are there other automations 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

• Does 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 students there may be a need to create service indicators for special types of applications.

There is 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 students 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 in wildly different ways 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

• Does 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

• Does 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.

• Student Financials → Tuition and Fees → Equation Variables

• Does 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

• Does 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

• Does 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 through.

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.

Every school will have custom tables and downstream dependencies that are unique to their environment. It is impossible to provide specific examples without understanding the individual school’s needs, but it is important to account for these during the integration design phase.

Summary

Integrating with PeopleSoft Campus Solutions to admit students is a multi-step process that touches many parts of the system. The key takeaways from this article are:

• There are very few delivered integration points. As the quick reference table shows, almost none of these steps have a delivered web service or component interface. Custom integrations are typically required.
• Search match is critical. Preventing duplicate records is one of the most important aspects of any admission integration. PeopleSoft does not have a way to easily merge duplicate student records, and fixing them is manual and time-consuming.
• Not every step is required. Steps like Application Data, Residency Data, Service Indicators, Equation Variables, and Student Groups are optional depending on the school’s business process. Understand what is actually needed before building integrations for every table.
• Every school is different. The way schools use action codes, career numbers, catalog years, and program/plan stacks varies widely. You cannot build a generic integration and expect it to work across institutions without significant configuration.
• Downstream processes matter. Creating a student in PeopleSoft often triggers downstream processes like SSO account creation, LMS provisioning, and financial aid processing. The data must be written correctly for those processes to fire as expected.

Questions to Ask During Integration Planning

If you are starting a CS admission integration project, here are questions I recommend discussing with the functional team early:

1. What is the search match strategy? What fields are available and what confidence level is acceptable for automated matching?
2. For matched students, what data gets updated and what gets preserved?
3. Are the PeopleSoft application tables (ADM_) needed, or can you skip directly to matriculation?
4. How are re-admitted and returning students handled? What about students with prior academic history?
5. What action and reason codes are required at each step, and in what order?
6. Are there service indicators or student groups that need to be set during the admission process?
7. What downstream systems depend on this data, and what assumptions do they make about how it is entered?
8. Are there custom tables or fields that the integration needs to populate?
9. Who handles the manual review when search match returns potential duplicates?
10. What is the security model? Who can see what data during the process?