Managing PeopleSoft Admission Transactions - Lee College

Oracle’s PeopleSoft 9.0 Recruiting and 

Admissions: Managing PeopleSoft 

Admission Transactions 

April 2011

9.0 

Oracle’s PeopleSoft 9.0 Recruiting and Admissions: Managing PeopleSoft Admission Transactions 

SKU lsad and lssr doclet 

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. 

Trademark Notice 

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their 

respective owners. 

License Restrictions Warranty/Consequential Damages Disclaimer 

This software and related documentation are provided under a license agreement containing restrictions on use and 

disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement 

or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, 

exhibit, perform, publish or display any part, in any form, or by any means. Reverse engineering, disassembly, or 

decompilation of this software, unless required by law for interoperability, is prohibited. 

Warranty Disclaimer 

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find 

any errors, please report them to us in writing. 

Restricted Rights Notice 

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the 

U.S. Government, the following notice is applicable: 

U.S. GOVERNMENT RIGHTS 

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers 

are “commercial computer software” or “commercial technical data” pursuant to the applicable Federal Acquisition 

Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and 

adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, 

to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, 

Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, 

CA 94065. 

Hazardous Applications Notice 

This software is developed for general use in a variety of information management applications. It is not developed 

or intended for use in any inherently dangerous applications, including applications which may create a risk 

of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all 

appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of this software. Oracle 

Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous 

applications. 

Third Party Content, Products, and Services Disclaimer 

This software and documentation may provide access to or information on content, products and services from third 

parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind 

with respect to third party content, products and services. Oracle Corporation and its affiliates will not be responsible 

for any loss, costs, or damages incurred due to your access to or use of third party content, products or services.

Contents 

Chapter 1 

Managing PeopleSoft Admission Transactions................................................ ..........1 

Admission Applications Web Services (AAWS)......................................................................1 

Prerequisites..........................................................................................................2 

External Search/Match and AAWS.................................................................................2 

Using Applicant and Administrator Modes for AAWS............................................................2 

Bulk Loading of Applications Using File Parser............................................................ ..........3 

CRM for Higher Ed EIPs and Admission Transactions..............................................................4 

Setting Up Admission Transactions....................................................................................4 

Pages Used to Set Up Admission Transactions..................................................................6 

Setting Up Counters .................................................................................................9 

Defining a Transaction...............................................................................................9 

Defining the Search/Match Criteria...............................................................................19 

Defining Data Update Rules for Batch and Online Application Transactions...............................21 

Setting Up Affiliation Overrides for a Data Update Rule.......................................................27 

Mapping Online Application Transactions to Academic Careers.............................................28 

Setting Up Application Defaults for Batch and Online Application Transactions...........................29 

Setting Up Prospect Creation Rules and Defaults for Batch and Online Application 

Transactions.........................................................................................................32 

Setting Up Home or Unlisted Schools for Online Application Transactions.................................34 

Setting Up List of Values for Online Applications...............................................................36 

Maintaining and Extending Data for Online and Batch Transactions........................................41 

Creating a Unit Test................................................................................................46 

Running Entity Unit Test Cases...................................................................................50 

Reviewing and Processing Staged Admission Transactions............................................. ........54 

Pages Used to Review and Process Staged Admission Transactions......................................56 

Reviewing Applicant Error Messages and Transactions......................................................59 

Reviewing Applicant Details.......................................................................................64 

Reviewing Applicant Participation Details.......................................................................66 

Reviewing Applicant’s Additional Personal Information.......................................................68 

Reviewing Applicant’s Regional Information....................................................................71 

Reviewing Application Error Messages and Application Data................................................72 

Reviewing Applicant’s Education History........................................................................79 

Reviewing Additional Academic Information....................................................................81 

Reviewing General Materials and Attachments................................................................81 

Copyright © 1992, 2011, Oracle and/or its affiliates. All rights reserved. 

iii

Contents 

Reviewing Application Regional Information....................................................................82 

Updating and Posting Transactions in Batch...................................................................83 

Specifying Search/Match Parameters for Batch Processing................................................. 86 

iv 

Copyright © 1992, 2011, Oracle and/or its affiliates. All rights reserved.

CHAPTER 1 

Managing PeopleSoft Admission Transactions 

This PeopleBook chapter includes bundle documentation up to Bundle 21. This chapter was first released for Bundle 

18 when the AAWS feature was introduced. The last release of the chapter was for Additional Features January 

2011 - AAWS Application Fee (Bundle 20). You can find the Bundle 21 documentation updates in this chapter by 

searching for the words Bundle 21. 

This chapter discusses: 

• Admission Applications Web Services (AAWS). 

• Bulk loading of applications using File Parser. 

• CRM for Higher Ed EIPs and admission transactions. 

• Setting up admission transactions. 

• Reviewing and processing staged admission transactions. 

Admission Applications Web Services (AAWS) 

The PeopleSoft system delivers web service operations that enable your online application to interface with the 

Campus Solutions system. The AAWS User’s Guide contains details about the following service operations: 

• Create Application 

• Save Application 

• Submit Application 

• Get Application 

• Get Applications 

• Get Attachment 

• User Registration 

• User Authentication 

• Get List of Values 

Note. The "Setting Up Self-Service Request Information and Using Self-Service Student Recruiting" chapter 

in the PeopleSoft Enterprise Recruiting and Admissions 9.0 PeopleBook is no longer supported. Oracle 

expects that academic institutions will use AAWS to develop and deploy their self service online applications. 

Copyright © 1992, 2011, Oracle and/or its affiliates. All rights reserved. 1

Managing PeopleSoft Admission Transactions Chapter 1 

See Also 

AAWS User’s Guide 

AAWS Developer’s Guide 

Enterprise PeopleTools PeopleBook: Integration Broker 

Prerequisites 

Complete the following post installation setups described in the AAWS Developer’s Guide: 

• Verify web service security settings. 

• Set up user accounts. 

• Perform a security analysis. 

• Publish web service. 

• Refresh the HCM registry cache. 

• Set up Integration Broker. 

• Verify Campus Solutions SOA framework setup entries. 

• Verify Constituent Transaction Manager setup entries. 

• Set up attachments URL. 

External Search/Match and AAWS 

If you want the system to search for duplicate records in an external system when a user submits an online 

application through AAWS, ensure that the CWS External Search/Match is set up. 

See Also 

PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook - Update 1, "Setting Up 

Search/Match" 

PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook - Update 1, "SettingUpExternal 

Search/Match" 

Using Applicant and Administrator Modes for AAWS 

The Applicant mode is also known as the Self Service mode. In this mode, an applicant creates and submits an 

admission application through AAWS. 

In the Administrator mode, the administrative user creates and submits an application on behalf of an 

applicant. The administrator may create the application for an existing EMPLID (if the administrator knows 

the applicant’s ID when creating the application), or for an unknown or new applicant. 

In the Administrator mode, the system associates the application with the administrator’s user ID. You can 

view this association on the Application Transactions component when reviewing the submitted applications. 

In other words, you can use the Application Transactions component to see which administrator has created an 

application for an applicant. 

In the Applicant mode, the system associates the application with the applicant’s user ID. 

2 Copyright © 1992, 2011, Oracle and/or its affiliates. All rights reserved.

Chapter 1 


In both modes, the system uses the Search/Match setup to determine which application records it should load 

into your database as new records, which records it should append to existing records in your database, which 

records it should suspend for your further review, and which records should be ignored. 

In the Administrator mode, the user must provide an institution and application center to create an application. 

The system enforces application center and academic structure security for the administrative user. 

If an administrator saves an application, another administrator cannot submit it through AAWS. However, the 

other administrator can use the Application Transactions staging component to update the application status 

to submitted and post the application. 

In the Administrator mode, the Get Applications service call returns only in-progress applications, that 

is, applications which have not been posted or cancelled. It is optional for an administrator to provide an 

EMPLID for a Get Applications call. If the administrator does not provide an applicant’s EMPLID, the system 

returns all the in-progress applications. 

The Administrator mode is activated by the presence of this optional parameter in an incoming message: 

. For example, an online application might send this message to Campus Solutions 

for administrator mode: 

 

UGRD 

Userid 

AD1234 

 

The AAWS User’s Guide lists the parameters that an online application and the Campus Solutions system 

exchange through AAWS. 

See Also 

PeopleSoft Enterprise Campus Solutions 9.0 Application Fundamentals PeopleBook, “Securing Recruiting 

and Admissions” 

PeopleSoft Enterprise Campus Solutions 9.0 Application Fundamentals PeopleBook, “Securing Your 

Academic Institution” 

Bulk Loading of Applications Using File Parser 

You can use the PeopleSoft File Parser utility to load applications from an external file into Campus Solutions. 

The external file can be a delimited file or a flat file. 

See Also 

AAWS Developer’s Guide 

Updated "Using the File Parser Process" Campus Community PeopleBook chapter. 



CRM for Higher Ed EIPs and Admission Transactions 

Enterprise Integration Points (EIPs) enable your institution to exchange data between CS and CRM. EIPs 

publish data either whenever data updating happens for the given entities of the EIPs or when the user requests 

data. This data can be created, updated, or deleted through various channels like components, component 

interfaces, and batch processes. 

The system publishes the following EIPs when an application that is submitted through AAWS or File Parser 

process is posted: 

• SAD_ADM_PRSPCT_DATA_SYNC 

• SAD_ADM_APPL_DATA_SYNC 

• SAD_TEST_SCORES_SYNC 

• SAD_ADM_INTEREST_SYNC 

• SSR_EXTRACUR_ACTVTY_SYNC 

• SAD_EXT_ACAD_DATA_SYNC 

• SCC_PERSON_SYNC 

The system can publish SAD_ADM_PRSPCT_DATA_SYNC when the system creates a prospect record for 

a saved or posted application. You use the Prospect Setup page to indicate when (upon save or post) the 

system should create a prospect record. The Prospect Setup page is discussed in the “Setting Up Prospect 

Creation Rules and Defaults” section of this chapter. 

See Also 

PeopleSoft Enterprise Campus Solutions 9.0 Application Fundamentals PeopleBook - Update 1, “Introducing 

Customer Relationship Management for Higher Education” 

CRM for Higher Education Developer’s Guide 

Setting Up Admission Transactions 

Campus Solutions generates a transaction when: 

• An applicant or administrator uses an online application to register for a user name and password through 

the User Registration web service operation (online transaction). 

• An applicant or administrator uses an online application to create, save or submit an application through 

AAWS (online transaction). 

• You use the File Parser utility to load applications from an external file (batch transaction). 

An admissions-related online or batch transaction includes both the constituent and application data. 

Constituent data may include person data or data that is considered as not associated with the application. 

Examples of constituent data include Name, Gender, Address, and Email. Examples of application data include 

Academic Program, Admit Term, and Academic History. 


Chapter 1 


When a transaction is generated, the system uses Search/Match to look for constituent data in your production 

environment (based on the Search/Match parameters) that matches the constituent data in the transaction. Each 

defined transaction can have its own Search/Match setup. You can therefore determine the rules for creating 

a new ID, updating an existing ID, suspending or ignoring a record. 

The system stores the constituent and application data in staging tables. If there are errors or if Search/Match 

determines that the incoming constituent record should be suspended or ignored, use the Constituent Staging 

and Application Transactions components to correct the admissions transaction data. You can post transactions 

individually or by batch to the Campus Solutions database. The Constituent Staging and Application 

Transactions components are discussed in the “Reviewing and Processing Staged Admission Transactions” 

section of this chapter. 

Before you deploy your online application or start loading the applications, you must set up the transactions. 

For AAWS, a minimum of two transactions must be set up: one for the data that a user submits through the 

new user registration service operation and another for the online application that a user saves or submits 

through the Save Application or Submit Application service operations. The following default transactions for 

user registration and online application are delivered with the system: 

• ADMISSIONS_REGISTRATION 

• ADMISSIONS_APPLICATION 

If you want to load admission applications using the PeopleSoft File Parser utility, set up a transaction for the 

batch load. 

Warning! For new user registration, do not define a new transaction. The system uses the 

delivered ADMISSIONS_REGISTRATION for AAWS user registration. Do not modify the 

ADMISSIONS_REGISTRATION transaction name because the system uses the name to register a user account. 

Academic institutions require different rules for updating constituent and application data based on a 

transaction and the affiliation the institution has with the constituent. For example, you may have a graduate 

online application rule where you want to update the constituent’s home email address in your database with 

the value from a submitted graduate application. On the other hand, you may have a graduate application load 

rule where you do not want to update an existing home email address value when you use File Parser to load 

graduate applications into Campus Solutions. Additionally, you may want to override this graduate application 

load rule if the constituent is a prospect. The Data Update Rule Entry component allows this flexibility. The 

system uses these rules when it posts a transaction. 

Different admission transactions may have different Search/Match settings and data update rules. For instance, 

an academic institution might allow undergraduate applicants to update their passport details when submitting 

an online application. Conversely, the institution might not want to allow graduate applicants to update their 

passport details if that data is already on the system. You can associate the two different data update rules to 

these two separate transactions. Both these transactions may or may not have different Search/Match settings. 

When establishing transactions, a single transaction for each institution and career combination could 

be defined. In this way, you can accommodate online applications for different careers (Examples: 

Undergraduate, Graduate, Graduation Business) which may have different Search/Match requirements, data 

update rules, or intended methods of processing. 

It is typical for administrators to enter the admissions application data for an applicant. It is possible for an 

administrator to use the same online application to do so, as long as the application user interface is constructed 

to distinguish between an administrator log in and a self service applicant log in. 

Administrators can use a different institution-developed user interface designed for quick data entry. The same 

transaction value applied to the self service application is utilized for the institution/career combination for 

which the application is being created. 



Use the Transaction Setup component to define a transaction, associate a data update rule with the transaction, 

and define the Search/Match setting for the transaction. Note that you cannot define a Search/Match setting 

for the user registration transaction. The new user registration feature does not ask the user enough personal 

information for creating a new ID. Also, a new user may createauserIDandpasswordwithoutevercoming 

back to fill out an online application. The information entered as part of the new user registration process is 

therefore kept in the constituent data staging table until the user actually performs a transaction. 

Applications typically vary among institutions and academic careers. Use the Appl Config page in the 

Application Configuration component to map an institution and career to a transaction. The system uses this 

mapping to identify which transaction to use when it receives an application through AAWS. For example, 

suppose you have defined two transactions: UG Transaction for undergraduate applications and Grad 

Transaction for graduate applications. When an applicant submits an undergraduate application, the system 

looks at the Appl Config page settings to determine that it needs to use the UG Transaction. 

This section discusses how to: 

• Set up counters. 

• Define a transaction. 

• Define the search/match criteria for a transaction. 

• Define data update rules for batch and online application transactions. 

• Set up affiliation overrides for a data update rule. 

• Map online application transactions to academic careers. 

• Set up application defaults for batch and online application transactions. 

• Set up prospect creation rules and defaults for batch and online application transactions. 

• Set up home or unlisted schools for online application transactions. 

• Set up list of values for your online application. 

• Maintain and extend data for online and batch transactions. 

• Create a unit test. 

• Run entity unit test cases. 

Pages Used to Set Up Admission Transactions 

Page Name Definition Name Navigation Usage 

Counter Setup SCC_AWS_FIX_CTRS Set Up SACR, System 

Administration, Utilities, 

Constituent Transaction 

Mgmnt, Counter Setup 

Set up the max ID number 

for the Temporary 

Constituent ID. 

Transaction Setup SCC_TRANSAC_DTLS • Set Up SACR, System 



Mgmt, Transaction Setup 

• Student Admissions, 

UCAS Processing, 

Search/Match Processing, 

Transaction Setup 

Define the transaction for 

an online transaction or a 

batch transaction. 


Chapter 1 



Search/Match Setup SCC_SEARCH_PARMS • SetUpSACR,System 



Mgmt, Transaction Setup, 

Search/MatchSetup 

• Student Admissions, 

UCAS Processing, 

Search/Match Processing, 

Transaction Setup, 

Search/Match Setup 

Define the Search/Match 

criteria for an online 

transaction or for running 

Search/Match manually 

from the Constituent Staging 

component. 

Not applicable for the user 

registration transaction. 

Data Update Rule Entry SCC_DUR_ENTRY Set Up SACR, System 



Mgmt, Data Update Rule 

Entry 

Affiliation Overrides page SCC_DUR_AFL_OVRD Set Up SACR, System 



Mgmt, Data Update Rule 

Entry, Affiliation Overrides 

Appl Config SAD_TRANSAC_MAP Set Up SACR, Product 

Related, Recruiting and 

Admissions, Application 

Configuration, Application 

Configuration, Appl Config 

Application Setup SAD_APL_CNT Set Up SACR, Product 





Setup 

Define how the constituent 

data is processed for an 

online transaction or batch 

transaction. 



Overrideadataupdaterule 

based on the affiliation the 

constituent has with the 

academic institution. 



Map online application 

transactions to academic 

careers. 

Not applicable for user 

registration. 

Define how the system 

should assign an application 

center and optionally assign 

3Cs to anapplicationby 

defining which Event 

ID should be used in the 

processing. The system 

uses this setup when you 

load applications in batch 

or when the user saves or 

submits an application 

through AAWS. 






Prospect Setup SAD_PRS_SETUP Set Up SACR, Product 




Configuration, Prospect 

Setup 


should create a prospect 

record, and if a prospect 

record is created, how to 

assign default values to the 

prospect record. The system 


process applications in batch 



through AAWS. 



School Setup SAD_AWS_SCH_DFL Set Up SACR,Product 




Configuration, School Setup 


should process unlisted or 

home schools. The system 


load applications in batch 



through AAWS. 



List of Values Setup SCC_SL_LOV Set Up SACR, Product 



Configuration, List of Values 

Entity Registry SCC_ENTITY_REG Set Up SACR, System 

Administration, Entity, 

Entity Registry 

Entity Unit Tests (Setup) SCC_ENTITY_UT Click the View Unit Tests 

button on the Entity Registry 

page. 

Entity Unit Tester SCC_ENT_MASS_UT Set Up SACR, System 

Administration, Entity, 

Entity Unit Tester 

Entity Unit Tests SCC_ENTITY_UT Click the View Unit Tests 

link from the Entity Unit 

Tester page 


should return the list of 

values for a field. The 

system uses this setup when 

the online application calls 

the Get List of Values service 

operation. 

Maintain and extend the data 

structure that represents 

the information collected 

from an online application or 

batch load. 

Attach the unit test 

application classes to an 

entity. 

Run all the unit tests 

associated with a specified 

entity. Unit tests are defined 

on the Entity Unit Tests 

(Setup) page. 

View the unit tests tied to an 

entity name, the application 

class used and the latest run 

status for a specific unit test. 


Chapter 1 


Setting Up Counters 

Access the Counter Setup page (Set Up SACR, System Administration, Utilities, Constituent Transaction 

Mgmnt, Counter Setup). 

Counter Setup page 

The field on this page is automatically incremented by one by default when using the Constituent Transaction 

Manager functionality. Set the last used number so that automatic numbering does not create numbers that 

already exist in the data. 

Temp Constituent ID 

Fix Counter 

Displays the last Temporary Constituent ID assigned. A Temp Constituent ID 

is given when a transaction is performed from the Constituent Transaction 

Manager framework. 

See “Defining a Transaction” and “Reviewing Applicant Error Messages and 

Transactions” sections, for more information. 

Clicking this button resets the Temp Constituent ID based on the highest 

value of that field in the database. The field is dynamically found based on 

the Peopletools metadata for the record field relationships, and the max 

possible value for that field across all possible records is set as the counter. 

This avoids the possibility of the system trying to reuse an ID and being 

polluted by pre-existing data. 

Note. After you have begun using the Constituent Transaction Manager functionality, you can access this page 

to determine the last number that was incremented for the Temporary ID. Manually changing this number is 

practical for the initial setup, but not recommended for further changes. If the ID entered is changed to an 

existing number, the system will attempt to re-use the ID. Instead use the Fix Counter button. 

Defining a Transaction 

Access the Transaction Setup page (Set Up SACR, System Administration, Utilities, Constituent Transaction 

Mgmt, Transaction Setup). 

This is an example of the delivered sample online application transaction: 



Transaction Setup page: Online application transaction (1 of 2) 


Chapter 1 


Transaction Setup page: Online application transaction (2 of 2) 

This is an example of the delivered new user registration transaction: 



Transaction Setup page: New user registration transaction (1 of 2) 

Transaction Setup page: New user registration transaction (2 of 2) 

This is an example of a transaction for the File Parser batch load of applications: 


Chapter 1 


Transaction Setup page: File Parser batch load transaction (1 of 2) 



Transaction Setup page: File Parser batch load transaction (2 of 2) 

For a File Parser batch load you must clear the Online Transaction check box and select the Batch option. 

Also, set up the transaction code for the batch load of applications on the Mapping page of the File Mapping 

Definition component. You can set this code as a default value (by default, the SCC_TRANSAC_CD field in 

the SCC_STG_CONSTIT record stores the transaction code). The File Parser process can also retrieve the 

transaction code directly from the load file (in such a case, set the mapping action to Direct from file). For 

more information about the File Mapping Definition component, refer to the updated Campus Community 

File Parser PeopleBook chapter. 

Transaction 

Transaction Status 

Data Update Rule 

Indicates the transaction code. 

You specify the transaction code when you add a transaction. 

Activate or inactivate the transaction. 

Select the data update rule that you want the system to apply to the constituent 

(person) data managed by this transaction. You define a data update rule in 

the Data Update Rule Entry page. 

Transaction Options 

Online Transaction 

New User Registration 

Select to indicate that the transaction is performed online by a user. For 

example, an online transaction occurs when an applicant saves or submits an 

admission application through AAWS. 

Clear this check box to indicate that the transaction is performed offline by a 

user. For example, an offline transaction occurs when you use File Parser to 

load applications from a text file. 

Select to indicate that the transaction is used to perform registration and 

authentication of a new user. 

If you select this check box, the system hides the Search/Match Setup tab and 

the Transaction Data Launch View group box, because they are not applicable 

for a new user registration transaction. 


Chapter 1 


Note. Your system allows for only one transaction to be set as new user 

registration at a time. The ADMISSIONS_REGISTRATION transaction is 

delivered with your system. Because of this restriction, the system hides the 

New User Registration check box for all other transactions. Do not modify the 

ADMISSIONS_REGISTRATION transaction name because the system uses 

the name to register a user account. 

Batch 

Realtime 

RunonSave 

Select if you do not want the system to immediately run Search/Match when 

the data is individually submitted. If you select this option, the system stores 

the submitted data in staging tables and you will need to run the Transaction 

Management process to run Search/Match and post the submitted data to 

Campus Solutions. 

Select to have the system immediately run Search/Match when the data is 

saved or submitted from an online or offline process. 

This check box appears if the Realtime check box is selected. 

Select this check box if you want the system to immediately run Search/Match 

when a user saves a transaction. 

Clear this check box if you want the system to immediately run Search/Match 

when a user submits a transaction. 

Warning! Selecting Run on Save will trigger Search/Match immediately after user saves the transaction. 

Make sure your user interface requires sufficient personal information to be entered so that there is enough 

data to populate the search criteria used by Search/Match. Otherwise, Search/Match could create a new ID 

or update an existing record with erroneous or missing information. 

Transaction Handler 

A transaction can contain generic information about a constituent (such as names, addresses, and date 

of birth), as well as data specific to the transaction. For example, an admission transaction will include 

personal information (constituent data) and application data (transaction data). You can use the Transaction 

Handler group box to define how the system should handle all the transaction data. You can create your 

own PeopleCode application class handler for the transaction data and then associate that application class 

with the transaction in this group box. 

The following table lists the delivered transaction handler values for ADMISSIONS_APPLICATION. Do 

not change these values. Also use these values when defining a transaction handler for any new application 

transactionyoumaycreate. 

Root Package ID Path Application Class ID 

SCC_OLA TRANSACTION AdmissionTransaction 

The following table lists the delivered transaction handler values for ADMISSIONS_REGISTRATION. 

Do not change these values. 


SCC_OLA TRANSACTION DefaultTransaction 



Transaction Status: The system needs a field in transaction staging tables where it can store the status of 

the transactions. Use the Transaction Status region to indicate the record and field where the transaction 

status is stored. 

The following table lists the delivered transaction status setup values for ADMISSIONS_APPLICATION. 

Do not change these values. You should always use these values when defining a transaction status setup for 

any new application transaction you may create. 

Record Name Field Name Date Field Name 

SAD_APL_DAT_STG SAD_APPL_STS SAD_APPL_STS_DT 

The following table lists the delivered transaction status setup values for ADMISSIONS_REGISTRATION: 

Record Name Field Name Date Field Name 

SCC_STG_CONSTIT SCC_STG_STATUS SCC_STG_STS_DT 

Constituent Handler 

You can use the Constituent Handler group box to define how the system should handle the constituent data in 

a transaction. You can create your own PeopleCode application class handler for the constituent data and then 

associate that application class with the transaction in this group box. 

The default application class that handles the constituent data is delivered with the system. You can modify 

this application class or create a new application class. 

The following table lists the default constituent handler values. You should always use these values when 

defining the constituent handler values for an online application transaction or batch load transaction. 


SCC_SL_TRANSACTION INTFC DefaultConstituent 

Partition Data 

Use the following options to indicate how the system should maintain the data in the staging tables. 

By Constituent 

By Transaction 

Select this option to have the system maintain only one instance of the 

constituent data for all transactions of the constituent (that is, One Constituent 

: Multiple Transactions ratio). This means that constituent data updates 

performed within a single transaction are visible across all other transactions. 

An example of the By Constituent impact: An applicant (user ID: Gina) has 

used an online application to register for a user account and then, later on, 

saved or submitted four admission applications. The system creates a total 

of five transactions for Gina, one transaction for user registration and four 

transactions for the four applications. For all the five transaction records, the 

system maintains a single constituent record. Gina updates her email address 

when saving or submitting the fourth application. The system updates Gina’s 

constituent record with the new email address. 

Select this option to have the system maintain a separate instance of constituent 

data for every transaction of the constituent (that is, One Constituent : One 

Transaction ratio). This means that constituent data updates performed within 

a single transaction are not visible across all other transactions. An example of 

the By Transaction impact: An applicant (user ID: Jason) has used an online 


Chapter 1 


application to register for a user account and then, later on, saved or submitted 

four admission applications. The system creates a total of five transactions 

for Jason. For all the five transaction records, the system maintains five 

constituent records of Jason. Jason updates his email address when saving or 

submitting the fourth application. The system updates Jason’s constituent 

record related to the fifth transaction with the new email address but does not 

update his other four constituent records. 

If you have selected By Constituent, the Summary Information page of the Constituent Staging component 

displays multiple transaction rows in the Related Transaction region (if multiple transactions exist for the 

constituent). When you search for transactions of a user who has multiple By Constituent transactions, 

the Constituent Staging component automatically displays the Summary Information page of the user with the 

related transactions. In the following example, the partition data by constituent option has been selected for the 

ADM_CONSTITUENT1 transaction and, therefore, the Summary Information page displays the constituent 

Elizabeth’s multiple ADM_CONSTITUENT1 application transactions on a single page. 

Partition Data By Constituent (Summary Information page) 

If you have selected By Transaction, the Summary Information page of the Constituent Staging component 

always displays only one transaction row in the Related Transaction region (even if multiple transactions exist 

for the constituent). When you search for transactions of a user who has multiple By Transaction transactions, 

the Constituent Staging component displays multiple search results. In the following example, the partition 

data by transaction option has been selected for the ADMISSION_APPLICATION transaction and, therefore, 

the system displays multiple search results for the constituent Jonathon. 



Partition Data By Transaction (search results) 

In the following example, you can see that the Summary Information page displays only one application 

transaction for the constituent because the partition data by transaction option has been selected for the 

ADMISSION_APPLICATION transaction: 

Partition Data By Transaction (Summary Information page) 

If you have selected the partition by transaction option, the system assigns a unique temporary ID to each 

transaction that the system generates for the constituent. If you have selected the partition by constituent option, 

the system assigns a unique temporary ID to all the transactions that the system generates for the constituent. 


Chapter 1 


See “Reviewing and Processing Staged Admission Transactions” section in this chapter for information 

on the Constituent Staging component. 

For the User Registration transaction, we recommend that you select the By Constituent option. 

Note. The preceding two graphics of the Summary Information page do not show the Created By field. 

This new field has been added to all the pages of the Constituent Staging and Application Transactions 

components for Bundle 21. Refer to the “Reviewing and Processing Staged Admission Transactions” section 

for more information. 

Note. In the AAWS administrator mode, the system always generates a temporary ID for each application that 

an administrator creates, regardless of whether you have selected the By Transaction or By Constituent option. 

In other words, the system does not support partition by constituent for the administrator mode. 

Transaction Data Launch View 

This group box indicates how you can access the transaction details by clicking a link on the Summary 

Information page of the Constituent Staging component. By default, the text you enter in the Transaction 

Name field becomes the label for the link on the Related Transactions grid of the Summary Information page. 

The following table lists the delivered Transaction Data Launch View settings for ADMISSIONS_ 

APPLICATION transaction. You should always use these values when defining the transaction data launch 

view settings for any new application transaction you may create. 

Menu Name Menu Bar Name Menu Item Name Menu Page Name 

Process Applications Use SAD_APPL_STG SAD_APPL_STG 

The Transaction Data Launch View group box is not available for user registration. Therefore, by default, the 

Summary Information page does not display a link for the user registration transaction. 

Defining the Search/Match Criteria 

Access the Search/Match Setup page (Set Up SACR, System Administration, Utilities, Constituent Transaction 

Mgmt, Transaction Setup, Search/Match Setup). 



Search/Match Setup page 

Note. The words “Parameters Refreshed” appear if this is the first time you have entered this page, or if any of 

the parameters on this page changed since the last time you accessed this page. 

Batch, Realtime and Run 

on Save 

Indicates the Search/Match options you have selected on the Transaction Setup 

page. These options are discussed in the "Defining a Transaction" section. 

Select a Search Type, Search Parameter, Search Result Code, and other search fields as appropriate. The 

values selected on this page are used behind the scenes when Search/Match is processed Realtime at the time 

the user saves or submits and from the Summary Information page when an administrator manually triggers 

Search/Match by clicking the Search/Match Results link for a specific transaction. 

To set up Search/Match when set to process by Batch, see the “Specifying Search/Match Parameters for 

Batch Processing” section. 

Note. Transaction Manager supports only person searches at this time. Therefore, the Search Type field 

defaults to Person and only Search Parameter and Search Result Code values set up for Person are valid. 

See PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook - Update 1, "Setting Up 

Search/Match" for information about setting up Search/Match rules, order, parameters, and results. 

See PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook - Update 1, "Setting Up 

External Search/Match" 


Chapter 1 


Match(es) Found 

This group box contains one row for each search rule defined in the Search Parameter selected. Define 

Search/Match orders and Search/Match rules on the Search/Match Rule page. 

Search Order Nbr (search 

order number) 

One Match and Multiple 

Matches 

For each order number, select what you want to do with the incoming record if 

the search/match/post process discovers one or more matching records. 

Select whether you want to add, update, suspend, or ignore matching records: 

Add: Addanewrecord to your database using the staging table record. 

Update: Update the existing record with the data in the staging table record. 

No Match Found 

Note. Updates are dependent on what has been defined as update rules on the 

Data Update Rule Entry component. 

Suspend: Suspend any processing of the staging table record. Use the 

Constituent Staging component to determine manually whether or not this 

staged record matches a record in your database. The Constituent Staging 

component is discussed in the “Reviewing and Processing Staged Admission 

Transactions” section of this chapter. 

Ignore: Ignore the staging table record that matched a record in your database. 

Select one of the following options to specify what Search/Match should do when it does not find a matching 

record in your database or the external system if you use External Search/Match: 

Add: Addtheunmatched record, including personal data, to your database. 

Suspend: Keep the unmatched record in the staging tables to be looked at manually. Use the Constituent 

Staging component to review the record. 

Ignore: Ignore the unmatched record completely. 

See Also 

AAWS User’s Guide, “Configuration Hints and Tips”, Constituent Transaction Manager 

Defining Data Update Rules for Batch and Online 

Application Transactions 

Access the Data Update Rule Entry page (Set Up SACR, System Administration, Utilities, Constituent 

Transaction Mgmt, Data Update Rule Entry). 



Data Update Rule Entry page (1 of 4) 


Chapter 1 







Chapter 1 



A data update rule defines whether or how transactions can update data in the constituent production tables. 

When you add a new data update rule, the Data Update Rule Entry page displays only those entities for which 

the Apply Data Update Rule check box is selected. This check box is available on the Entity Registry page 

(Set Up SACR, System Administration, Entity, Entity Registry). 

Refer to the AAWS Developer’s Guide and the “Maintaining and Extending Data for Online and Batch 

Transactions” section in this chapter for information about the Entity Registry page. 

The default value for Update Action is Do Not Update. 

Copy 

Refresh 

Set All Actions To 

Entity Name 

Staging Record 

Entity Type 

Click to access the Copy Data Update Rule page and copy an existing rule’s 

settings to the new rule. 

Click to refresh the entities populated on the Data Update Rule Entry page. 

When you click the button, a message appears indicating which entities have 

been added or removed from the page. 

For example, suppose you added a new entity and selected the Apply Data 

Update Rule check box on the Entity Registry page. In such a case, you must 

click the Refresh button to populate the Data Update Rule Entry page with this 

new entity. Conversely, you cleared the Apply Data Update Rule check box 

on the Entity Registry page for an entity. In such a case, you must click the 

Refresh button to remove the entity from the Data Update Rule Entry page. 

Select an update action that you want to apply for all the entities. The 

update actions you can select are Add If Blank, Do Not Update, Safe Update 

(applicable for only non-type entities) and Update/Insert. 

Displays the name of the entity as defined on the Entity Registry page. 

Displays the staging record where the system stores the incoming entity data 

from a transaction. You define a staging record for an entity on the Entity 

Registry page. 

This field is only available for entities with multiple types, such as Address 

and Name entities. The default value is All. 

Select Show All Types to display all the types for an entity. Select this value 

if you want to specify a different update action for one or more types of an 

entity. For example, suppose you want to enter Update/Insert update action for 

campus address and Add If Blank update action for all the other address types 



Entity Field 

Update Action 

(such as home or billing). In such a case, select Show All Types for the Address 

entity and specify the update action for each address type. 

Select All if you do not want to display all the types for an entity. Select this 

value if you want to specify the same update action for all the types of an 

entity. For example, select All ifyouwanttoenterUpdate/Insert update action 

for all the address types (such as campus, home and billing). 

This field is only available for entities that do not have any types, such as 

Constituent and Diversity entities. 

Select Show All Fields to display all the fields of an entity. Select this value 

if you want to specify a different update action rule for one or more fields 

of an entity. For example, suppose you want to enter Do Not Update update 

action for Date of Birth field and enter Add If Blank update action for rest of 

the Constituent fields (such as Birth Location or Birth Country). In such a 

case, select Show All Fields for the Constituent entity and specify the update 

action for each Constituent field. 

Identify what the system should do when it posts the entity data to the 

production records of an existing constituent: 

Select Add IfBlankto add the entity data only if the constituent does not have 

the entity data. For example, suppose you have assigned Add If Blank to the 

Home Email Address entity type for the graduate application transaction. The 

system receives a graduate application with a home email address through 

file load or AAWS. The constituent does not have a home email address in 

the database. In such a case, the system adds the constituent’s home email 

address to the database. 

Select Do Not Update to prevent the constituent’s entity data from being 

updated. For example, suppose you have assigned Do Not Update to the 

National ID entity for the graduate application transaction. The system receives 

a graduate application with a National ID through file load or AAWS. The 

applicant already has a National ID on the production record of the database. 

In such a case, the system does not update the applicant’s existing National ID. 

Warning! Note that if the Do Not Update action is selected for an entity, the 

data will not be posted even if data does not exist on the production record. 

Select Safe Update to update or insert the constituent’s entity data only if the 

incoming data is populated. This action is available only for entities without 

a type. If the entity data has an effective date, then the system inserts new 

effective dated rows but does not overwrite existing fields with blank or zero. 

If the entity data does not have an effective date, then the system updates the 

existing record only for the fields where incoming data is populated. For 

example, suppose you have assigned Safe Update to the Constituent entity 

for the graduate application transaction. The system receives a graduate 

application with only Date of Birth and Birth Country populated for the 

Constituent entity through file load or AAWS. Birth State and Birth Location 

are not populated as part of the incoming data. The applicant already has Date 

of Birth, Birth Country, Birth State and Birth Location on the production 

record of the database. In such a case, the system updates Date of Birth and 

Birth Country with the incoming data but will not update Birth State and Birth 

Location as these fields are not populated as part of the incoming data. 


Chapter 1 


Select Update/Insert to update or insert the constituent’s entity data, even if the 

incoming and existing values are the same. If the entity data has an effective 

date, then the system inserts a new effective dated row if the incoming data 

differs from the current effective dated row. If the entity data does not have an 

effective date, then the system updates the existing record. 

Warning! Note that the Update/Insert action will update character-based fields 

to blank or null and numeric fields to zero if the field is not populated on the 

incoming entity. For example, suppose you have assigned Update/Insert to 

the Constituent entity for the graduate application transaction. The system 

receives a graduate application with only Date of Birth and Birth Country 

populated for the Constituent entity through file load or AAWS. Birth State 

and Birth Location are not populated as part of the incoming data. The 

applicant already has Date of Birth, Birth Country, Birth State and Birth 

Location on the production record of the database. In such a case, the system 

updates the applicant’s existing Date of Birth and Birth Country with the 

incoming data but will also update Birth State and Birth Location to blank. For 

this reason, use caution when selecting the Update/Insert action to prevent 

existing data from being updated to blank or zero. 

Refer to the next section “Setting Up Affiliation Overrides for a Data Update Rule” for information on how 

you can have the system update constituent data based on the affiliation the institution has with the constituent. 

See Also 

AAWS User’s Guide, “Configuration Hints and Tips”, Data Update Rules 

Setting Up Affiliation Overrides for a Data Update Rule 

Access the Affiliation Overrides page (Set Up SACR, System Administration, Utilities, Constituent 

Transaction Mgmt, Data Update Rule Entry, Affiliation Overrides). 

Affiliation Overrides page 

Note. To use Affiliation Overrides, Transaction Setup must be set to Partition by Transaction, Institution 

must be a field for the Record Name entered in the Transaction Status section of Transaction Setup, and the 

Affiliation Overrides page must be set up. 

Rule Name 

Institution and Affiliation 

Code 

Displays the name of the base update rule. 

Enter the academic institution and affiliation for which you want to override 

the rule defined on the Data Update Rule Entry page. 



Affiliation Override 

Rule ID 

Order 

For example, suppose for a rule name UGRD_APPLICATION you have 

defined an Update/Insert update action for the Home Address entity type. 

For the same rule, UGRD_APPLICATION, you can specify that if the system 

receives an application and the constituent has an affiliation of Employee for 

the PSUNV institution, apply a different rule that has an update action of Do 

Not Update for the Home Address entity type. 

Enter the overriding rule for the academic institution and affiliation 

combination. 

Indicate the order in which you want the system to check the override rule. 

The system applies the Affiliation Override Rule ID for the affiliation assigned 

to the constituent using the following criteria: 

• The highest order where the affiliation status is Active. 

• The affiliation start date is less than or equal to the date when the 

transaction is submitted. 

• The affiliation end date is either blank or greater than or equal to the date 

when the transaction is submitted. 

For example, if you have defined an override rule for PSUNV and Employee 

with order number 10 and another rule for PSUNV and Student with order 

number 20, the system evaluates the the Employee rule before the Student 

rule. If the constituent has active affiliations for both Employee and Student, 

the system applies the override rule for Employee. If the constituent has an 

active affiliation for only Student, the system applies the override rule for 

Student. If the constituent does not have an affiliation for either Employee or 

Student, the system applies the base update rule. 

Mapping Online Application Transactions to Academic Careers 

Access the Appl Config page (Set Up SACR, Product Related, Recruiting and Admissions, Application 

Configuration, Application Configuration, Appl Config). 

Appl Config page 


Chapter 1 


You can enter only online transactions (except user registration transaction) in the Transaction field. To check 

whether a transaction has been marked as Online or Batch, use the Transaction Setup page (Set Up SACR, 

System Administration, Utilities, Constituent Transaction Mgmt, Transaction Setup). 

See Also 

AAWS User’s Guide, “Configuration Hints and Tips”, Application Configuration 

Setting Up Application Defaults for Batch and Online 


Access the Application Setup page (Set Up SACR, Product Related, Recruiting and Admissions, Application 

Configuration, Application Configuration, Application Setup). 

Application Setup page: Criteria tab (1 of 2) 

Application Setup page: Criteria tab (2 of 2) 



Application Setup page: Assigned Values tab (1 of 2) 

Application Setup page: Assigned Values tab (2 of 2) 

Use the Criteria tab to define the selecting criteria — such as academic career, academic program, and 

academic plan — that will constitute a particular group of applications. Use the Assigned Values tab to 

define the application center and event ID that the system assigns to the particular application group. When 

the system receives an application, it uses this mapping to determine which application center and event 

ID should be assigned to an application. 

In the exhibit example — Application Setup page: Criteria tab (2 of 2) — you can see that for row 12, career is 

UGRD, program is AA and plan is Music. For the same row, in the exhibit example — Application Setup 

page: Assigned Values tab (2 of 2) — the application center is APP3. Assume that the system receives an 

application for a career of UGRD, program of AA, and plan of Music through AAWS or batch load. In such a 

case, the system assigns APP3 to this application. 


Chapter 1 


The system requires an application center to create an admission application. Therefore, you must map each 

career with an application center on the Application Setup page. The system generates an error message if it 

receives an application through AAWS or batch load and it does not find the corresponding application center 

from this mapping. You can view this error message on the Application Transactions staging component. Note 

that the system assigns an application center from this mapping when an application is saved or submitted. The 

system assigns the 3C Event ID when an application is posted. 

Note. You should complete this mapping for only applicant mode. In the administrator mode, the user 

provides the application center when creating an admission application. Therefore, this setup is not relevant 

for administrator mode. 

Criteria 

Career 

Program 

Plan 

Country and Citizenship 

Status 

Enter the career for which you want to assign an application center (and 

optionally, an event ID). 

Optionally, enter the program for which you want to assign an application 

center (and optionally, an event ID). 

If you leave this field blank, the system assigns the application center to 

all the programs within the career. For example, suppose you have two 

application centers: APP01 and APP02. Map the career GRAD and program 

MBA combination to the APP01application center and map the GRAD career 

to the APP02 application center. In such a case, the system will assign APP01 

application center to an MBA application and it will assign APP02 to other 

non MBA applications such as a MS or MA application. 

Optionally, if you have entered a program, enter the plan for which you want 

to assign an application center (and optionally, an event ID). 

If you leave this field blank, the system assigns the application center to all the 

plans within the program. For example, suppose you have two application 

centers: APP03 and APP04. Map the career GRAD, programMS, and plan 

Finance combination to the APP03 application center and map the GRAD 

career and MS program to APP04 application center. In such a case, the 

system will assign APP03 application center to an MS Finance application 

and it will assign APP04 to other Master of Science applications such as MS 

in Biochemistry or MS in Physics. 

Enter the country and citizenship if you want to assign an application center 

(and optionally, an event ID) based on the applicant’s citizenship. For 

example, you could have the career UGRD, country USA, and citizenship Alien 

Temporary mapped to an Undergrad International Office application center 

and GRAD, USA, andAlien Temporary mapped to a Graduate International 

Office application center. 

Note. If you enter a value in one of the two fields, you cannot leave the 

other field blank. For example, if you enter a country, you must specify 

the citizenship. 

Note. When determining the application center assignment, the system uses the following order: citizenship 

status, academic plan, academic program, and academic career. 



Assigned Values 

Enter the application center, and optionally the event ID, for the row entered on the Criteria tab. 

Only the event IDs that have the administrative functions ADMA (admissions application) and ADMP 

(admissions program) are available. ADMP is available only if you select an academic program on the Criteria 

tab. Define event IDs on the Event Definition page. 

See PeopleSoft Enterprise Campus Community 9.0 Fundamentals PeopleBook - Update 1, "Using the 3C 

Engine," Defining 3C Engine Events. 

See Also 


Setting Up Prospect Creation Rules and Defaults for Batch 

and Online Application Transactions 

Access the Prospect Setup page (Set Up SACR, Product Related, Recruiting and Admissions, Application 

Configuration, Application Configuration, Prospect Setup). 

Prospect Setup page: Criteria tab 


Chapter 1 


Prospect Setup page: Assigned Values tab 

Use the Criteria tab to specify whether you want the system to create a prospect when the user saves an 

application through AAWS or when you post an application to the Campus Solutions database. Also, 

on this tab define the criteria for creating the prospect. Use the Assigned Values tab to specify the default 

values that the system assigns to the prospect. You must specify the recruiting center, recruiting status, and 

referral source values. 

In the exhibit example — Prospect Setup page: Criteria tab — you can see that for row 3, career is MED, 

program is MED, planisPharmacology and Create Prospect value is SAVE. For the same row, in the exhibit 

example — Prospect Setup page: Assigned Values tab — values such as the recruiting center MPHA is 

assigned. Assume that a user saves an pharmacology application through AAWS. In such a case, the system 

creates a prospect record for the applicant and also assigns the default values such as the recruiting center 

MPHA to this newly created prospect record. 

Note. To create prospect on save, the online application must ensure that the required constituent data is 

collected before the user saves the application. 

Also, ensure that the related transaction is set to run real time on save. If the related transaction is set to 

run on submit, then the Prospect Setup page displays a warning message if you choose the Save option for 

Create Prospect. For example, suppose you have a transaction UGRD_online_app and you have mapped this 

transaction to the UGRD career and GLAKE institution on Appl Config page. You have not selected the Run 

on Save check box on the Transaction Setup page for this transaction. In such a case, the Prospect Setup page 

displays a warning message if you select the Save option for the UGRD and GLAKE criteria. If the prospect 

setup is set to create a prospect on Save, but the transaction is not set to run real time on Save, you can still 

create the prospect record by running the Transaction Management process for Saved transactions. 

Criteria 

Career 

Enter the career for which you want to create prospect records and assign 

default values. 



Program 

Plan 

Create Prospect 

Optionally, enter the program for which you want to create prospect records 

and assign default values. 

If you leave this field blank, the prospect records are created for all the 

programs within the career. 

Optionally, if you have entered a program, enter the plan for which you want 

to create prospect records and assign default values. 

If you leave this field blank, the prospect records are created for all the 

plans within the program or career. 

Identify how you want to create prospect records for the career (and program 

and/or plan, if applicable): 

Save: Select if you want the system to create a prospect record when it 

receives a Save Application service operation request or when the applications 

are loaded into the staging tables using File Parser and have a transaction 

status of Saved. 

Post: Select if you want the system to create a prospect record when the online 

or batch transactions are posted to the Campus Solutions database. 

If the prospect record already exists for the institution and career of the transaction, the system updates the 

prospect record to insert program and plan data that does not exist, and also inserts Housing Interest, Financial 

Aid Interest, Last School Attended and Graduation Date if not previously populated. 

Note. If you want to create prospects for all applications received for the criteria entered, enter a row for Save 

and a row for Post. This will ensure that the system will create a prospect record when an application is 

not saved prior to submission. 

Assigned Values 

Enter the recruiting center, recruiting status, referral source and optionally the event ID, for the row entered on 

the Criteria tab. 

Only the event IDs that have the administrative functions PROS (prospect) and PROP (prospect program) are 

available. PROP is available only if you select an academic program on the Criteria tab. Define event IDs 

on the Event Definition page. 

See Also 


Setting Up Home or Unlisted Schools for Online 


Access the School Setup page (Set Up SACR, Product Related, Recruiting and Admissions, Application 

Configuration, Application Configuration, School Setup). 


Chapter 1 


School Setup page 

An online application may need to capture the applicant’s academic history. The online application may 

present a field with a list of schools, colleges, and universities that exist in the system’s External Organization 

table and the user may select a value from this list. However, two applicant categories exist, those who have 

attended an academic institution that is not listed in the list of values (unlisted schools) and those who are 

home schooled. The online application may present a text field or some other method to capture the home 

or unlisted school details. Use the School Setup page if you want to define how the system should process 

these unlisted or home schools. 

Unlisted Schools 

Post Application Using 

Default 

Default Organization 

Select if you want to specify a default organization ID for unlisted schools or if 

the applicant has not provided the school name. 

This field appears if you select the Post Application Using Default option. 

Specify the default organization ID to post with the application record. 

Note. If the application contains multiple rows of Unlisted School data, the 

default will apply to the first processed row. Because External Organization 

ID is a key field, it is not possible to use the default more than once. In the 

event of multiple Unlisted Schools, the web service will create a reconciliation 

error in the staging component and will require manual reconciliation of the 

additional Unlisted School rows. 

Require Manual 

Reconciliation 

Select if you want to manually correct an application that has an unlisted 

school or no school. 



Home School 

If you select this option and if the application transaction has an unlisted 

school or no school, the system retains the transaction in the staging table with 

a constituent status of Error. You will have to resolve the error message and 

then post the application. You can use the Application Transactions component 

to select an appropriate External Org ID and run the post process. Refer to the 

“Reviewing and Processing Staged Admission Transactions” section of this 

chapter for more information on this component. 

Post Application Using 

Default 

Default Organization 

Select if you want to specify a default organization ID for home schools. 

This field appears if you select the Post Application Using Default option. 

Specify the default organization ID to post with the application record. 

Note. If the application contains multiple rows of Home School data, the 

default will apply to the first processed row. Because External Organization 

ID is a key field, it is not possible to use the default more than once. In the 

event of multiple Home Schools, the web service will create a reconciliation 

error in the staging component and will require manual reconciliation of 

the additional Home School rows. 

Require Manual 

Reconciliation 

Select if you want to manually correct an application that has a home school. 

If you select this option and if the applicant has mentioned home school, 

the system retains the transaction in the staging table with a constituent 

status of Error. You will have to resolve the error message and then post the 

application. You can use the Application Transactions component to select an 

appropriate External Org ID and run the post process. Refer to the “Reviewing 

and Processing Staged Admission Transactions” section of this chapter for 

more information on this component. 

See Also 


Setting Up List of Values for Online Applications 

An online application may present list fields for the users. These fields only accept input from a list of 

values. The list of values could be translate values or the values that you set up in Campus Solutions. The 

following is an example of a field with a list of values. 

A List field 


Chapter 1 


Your online application must use the Get List of Values service operation to retrieve the list of values for a 

field. This service operation looks at the default table record or column to retrieve the values for a field. 

However, if you want to control which values are sent back to the online application, use the List of Values 

Setup page. To access the List of Values Setup page, select Set Up SACR, Product Related, Recruiting and 

Admissions, Application Configuration, List of Values. 

List of Values Setup page 

For instance, in the exhibit example — List of Values Setup page — you can see that the applicant and 

administrator modes point to different tables for retrieving the admit type values. Therefore, to retrieve the list 

of values for an applicant, the service operation will use the ADMIT_TYPE_VW table. To retrieve the list of 

values for an administrator, the service operation will use ADMIT_TYPE_TBL. 

You set up admit types in the Admit Type Table page (Set Up SACR, Product Related, Recruiting and 

Admissions, Prospect/Applicant Recruiting, Admit Type Table). The page accepts a description and short 

description for an admit type. In the exhibit example — List of Values Setup page — the setup indicates 

that for self service users (applicants) the service operation will display the description, whereas for the 

administrator the short description will be displayed in the list of values. The exhibit example also shows that 

the setup does not display the RAD admit type (Readmit) to the applicant. 



This is an optional setup. Only the Get List of Values service operation can use this setup. Therefore, if your 

online application is not using the Get List of Values service operation to populate its lists of values, then you 

should not use this setup. Also, if you do not want to alter the default way in which the operation picks up the 

list of values for a field, then you should not use this setup. For example, suppose you have presented the user 

with an Admit Type drop down list. To display the admit type list of values, the Get List of Values service 

operation, by default, picks the values you have defined in the Admit Type Table. If you do not want to hide 

any of these values from the user or point to a different record to pick up the values, you need not use the 

List of Values Setup page for the Admit Type field. 

Record Name 

Field Name 

Indicates the table that contains the field values. 

You specify the record name when you add a list of values setup rule. 

Enter the field whose list of values you want to modify. 

Arecordmay have multiple fields and therefore multiple rows may exist in 

this page because: 

• The online application could be inserting data into multiple fields of 

this record. 

• One field is dependent on another field for its list of values. 

For example, the ADM_APPL_PROG record contains ACAD_PROG 

and ADMIT_TERM fields because the list of valid academic programs is 

dependent on an admit term. On an online application, the user must first 

specify an admit term and then the academic program. 

Self Service Mode 

Use this group box to control the list of values for applicants who will use your online application. 

This group box is available for only user defined list of values. Examples of fields that have user defined 

list of values include ACAD_CAREER and ADMIT_TYPE. This group box is not available for fields that 

have translate values. Examples of fields that have translate values include ACADEMIC_LEVEL and 

HOUSING_INTEREST. 

Edit Table 

Prompt 

Descr Field 

Select the table from which you want the service operation to retrieve the 

values. 

Note that the applicants may not have a user ID that is authorized to access a 

secure table. Therefore, you may need to select a table for which the system 

does not apply user ID security. 

You cannot use a dynamic view or a derived record as an edit table because 

they are not a reliable list of values source for the service operation. 

Select the column from which you want the service operation to retrieve 

the values. 

Select the description you want to display to the applicant. 

Administrator Mode 

Use this group box to control the list of values for administrators who will use your online application. This 

group box is available for only user defined list of values and is not available for fields that have translate 

values. 


Chapter 1 


Note that administrators will have a user ID that is authorized to access a secure table if you have set up the 

user ID security (Set Up SACR, Security, Secure Student Administration, User ID). 

Prompt Table Keys 

In some cases, the Field Name on the List of Values Setup page does not provide a list of valid values 

to choose from. This is because the field name you selected, by itself, does not give the system enough 

information to retrieve the appropriate set of values. That is, the values for the selected field are dependent on 

the values of one or more other fields. 

Use this group box to indicate the fields on which your list of values depend. Also, specify the order in which 

the service operation should collect data from these fields or specify a constant (default) for these fields. 

In the following example, you can see that the Prompt Table Keys group box specifies that the online 

application must first specify the academic career (such as undergraduate or graduate), then the admit term 

(such as 2011 Spring or 2011 Fall), and then the institution before displaying the academic program list 

of values. 

Prompt Table Keys: Request XML 



Select the Allow Blanks check box to indicate that the value from the dependent field can be blank. In 

the Request XML example, none of the Allow Blanks check boxes are selected because a value must be 

specified by the online application for each field. This allows the service operation to return a valid list of 

academic programs. However, in the List of Values Setup page example, the Admit Type field depends on the 

Academic Career field for its list of values and the Allow Blank check box has been selected for Academic 

Career. This is because the Admit Type table can store admit types for a specific career, but it can also 

store admit types for all careers. 

In the following example, you can see that the Prompt Table Keys group box specifies that the service 

operation should return to the online application a list of external organization values with a type of school 

for a School Attended field. 

Prompt Table Keys: Constant 

The Prompt Table Keys group box is available for only user defined list of values. This group box is not 

available for fields that have translate values. 

Excluded Values 

Use this group box if you want to exclude one or more values in a list. This group box is applicable for only 

self service users (applicants). 


Chapter 1 


Refresh LOV 

Delete All 

Value 

Click to populate the Excluded Values group box with the field’s values. If you 

use this choice, you can view all the valid values that the service operation will 

return for a field. 

Click to remove values from the Excluded Values region. 

Specify a value that you want to hide from the applicant user. 

This group box is available for both type of fields: fields that have user defined list of values and fields that 

have translate list of values. 

See Also 

AAWS User’s Guide, “Configuration Hints and Tips”, List of Values 

AAWS User’s Guide, List of Values Web Service Operation 

Maintaining and Extending Data for Online and 

Batch Transactions 

Access the Entity Registry page (Set Up SACR, System Administration, Entity, Entity Registry). 



Entity Registry page 

Note. Refer to the “Extending AAWS” section in the AAWS Developer’s Guide for more information about 

the Entity Registry page and how to create new entities. 

You can use the Entity Registry page to not only create new entities but also to maintain existing entities. 

For example, you can use the page to: 

• Specify that you do not want to apply a data update rule to an entity. 

• Change the application class that handles the entity data. 

• Change the staging or production table record. 


Chapter 1 


The PeopleSoft system delivers entities for the admission application and constituent data records. You can 

use the delivered entities as they are, modify them, or create your own. 

The following main constituent entities are delivered: 

• Constituent 

• Names 

• Address 

• Email Address 

• National ID 

The following miscellaneous constituent entities are delivered: 

• Person Data Effdt 

• Person Relation Affiliation 

• Person Relation Communication 

• Person Relationship 

• Person Relationship Salutation 

• Person SA 

• Emergency Contact 

• Emergency Phone 

• Diversity 

• Ethnicity Detail 

• Ethnic Diversity 

• Disability 

• Citizenship 

• Citizenship Passport 

• Visa Permit Data 

• Port of Entry Data 

• Publications 

• Languages 

• Licenses and Certificates 

• Drivers License Type 

• Drivers License 

• Memberships 

• Work Experience 

• Extracurricular Activities 

• Honors & Awards 

• Residency 

• Residency Appeal 



• Residency Official 

• Residency Self 

• Religious Preference 

• Academic Interests 

• Academic Interests Header 

• External System 

• External System Key 

• External System IDs 

• Student Career (Constituent) 

• File Attachment 

The following entities related to academic information are delivered: 

• Academic History 

• Test Score Component 

• Test Score 

• External Academic Data 

• External Degree 

• External Course Grade 

• External Course Communication 

• External Course 

• External Education Comment 

• External Academic Subject 

• External Academic Summary 

The following entities related to application and prospect information are delivered: 

• Application 

• Application Attachment 

• Application Fee Tender 

• Academic Program 

• Academic Plan 

• Academic Sub-Plan 

• Career Sequence 

• Q&A Application Extension 

• General Materials 

• Recruiter 

• Prospect Career 

• Prospect Plan 

• Prospect Program 


Chapter 1 


• Prospect Recruiter 

• Prospect Recruiting Category 

• Prospect Sub-Plan 

• Recruitment Category 

• Student Career (Prospect) 

• Student Response 

The following country-specific entities are delivered (constituent, application and student records): 

• Tribal Affiliation (NZL) 

• Person Data (NZL) 

• Academic Program (NZL) 

• HESA Person Data (UK) 

• HESA Person (UK) 

• Academic Program (AUS) 

• Citizenship History (AUS) 

• CHESSN (AUS) 

• CHESSN Prior HEP (AUS) 

• CHESSN Year 12 (AUS) 

• Student Data (AUS) 

• Student Report (CAN) 

• Person Data (CAN) 

• External Academic Data (CAN) 

• Application (NLD) 

• Academic Program (NLD) 

• Student Nationalities (NLD) 

• Student Names (NLD) 

• Scholarship Data (NLD) 

• Student Brincode (NLD) 

• Higher Ed Student Data (NLD) 

• Student Information (NLD) 

• Student Education (NLD) 

• Student Bank Account (NLD) 

• Student Correspondence (NLD) 

• Education Subject (NLD) 

• Student Prior Education (NLD) 

• Person Data (USA) 



See Also 

AAWS User’s Guide, “Configuration Hints and Tips”, Entity Registry 

AAWS Developer’s Guide, “Extending AAWS” 

AAWS Developer’s Guide, “Developer’s Reference” 

Creating a Unit Test 

Unit tests are small focused tests that academic institutions can use to ensure that each unit of code in an entity 

works properly. This is done to find errors in the smallest segments of code during development and allow 

them to be fixed early, resulting in higher quality code. 

Because the Entity Registry component is highly extensible, the system integrates unit testing with the Entity 

Registry, by delivering a unit test framework. 

Coding a Unit Test 

Each unit test must extend the class TestBase. 

There are three methods that the unit test can override in TestBase. 

• Setup(): Is the first method that your unit test must call. This method should be used to set up the 

environment for the test. If environment setup is not required, the unit test does not have to implement 

this method. 

• Run(): Is the main testing method. A unit test must run all the code relevant to executing the test in this 

method. If the test fails, the property status should equal the property FAILED. If the test runs successfully, 

the property status should be set to PASSED. This method must be overridden. 

• Teardown(): Is the method that does the cleanup. In theory, this method should reset all the data, as if 

the test had never been run, therefore, if required the test can be run again successfully. This method is 

optional, depending on your testing requirements. 

The full class reference for TestBase is presented in the SCC_COMMON:Testing:TestBase application class. 

This application class is described later in this section. 

The following code shows an example where a unit test retrieves a constituent that is based on TestBase: 

import SCC_COMMON:Testing:*; 

import SCC_COMMON:ENTITY:IEntity; 

import SCC_SL_TRANSACTION:INTFC:Constituent; 

class GetConstituent extends SCC_COMMON:Testing:TestBase 

method GetConstituent(); 

method setup(); 

method teardown(); 

method run(); 

end-class; 

method GetConstituent 

%Super = create SCC_COMMON:Testing:TestBase("GetConstituent"); 

end-method; 


Chapter 1 


method run 

/+ Extends/implements SCC_COMMON:Testing:TestBase.Run +/ 

Local SCC_SL_TRANSACTION:INTFC:Constituent &constituent = create 

SCC_SL_TRANSACTION:INTFC:Constituent( Null); 

/*Retrieves the constituent*/ 

&constituent.setStageMode( True); 

&constituent.EMPLID = "KU0004"; 

&constituent.fromProduction(); 

/*Prints in the message area the complete consitutent xml 

for the constituent received*/ 

Local XmlDoc &responseDoc = CreateXmlDoc(""); 

Local XmlNode &rootNode = 

&responseDoc.CreateDocumentElement("CONSTITUENT"); 

&constituent.toXmlNode(&rootNode); 

%This.Msg(&responseDoc.GenFormattedXmlString()); 

end-method; 

method setup 

/+ Extends/implements SCC_COMMON:Testing:TestBase.Setup +/ 

end-method; 

method teardown 

/+ Extends/implements SCC_COMMON:Testing:TestBase.Teardown +/ 

end-method; 

Attaching a Unit Test 

You attach a unit test to a specific entity. To attach a unit test to an entity: 

1. Navigate to the Entity Registry page for the entity to which you want to attach a unit test (Set Up 

SACR, System Administration, Entity, Entity Registry). Continuing with the previous code example, the 

following shows that the Constituent entity is selected. 



Example of the Entity Registry page for the Constituent entity 

2. Click the View Unit Tests button to access the Entity Unit Tests (setup) page. 

Example: Entity Unit Tests (setup) page for the Constituent entity 

Active 

Select to allow the system to run the unit test. 

If you clear this check box, the system ignores the unit test. 


Chapter 1 


Type 

Application Class 

Run Unit Tests 

OK 

Select a categorical classification of the unit test, this is mostly for description. 

Select the class that you have created for the unit test. In the previous exhibit 

example — Entity Unit Tests (setup) page for the Constituent entity — the 

MessageGenerator class is selected for the Constituent entity. 

Click to run the unit test. 

You can add any number of unit tests on this page and click this button once 

to run all the tests simultaneously. 

Click to save this unit test setup. 

The other fields on this page are similar to the Entity Unit Tests (view-only) page that is described in the next 

section “Running Entity Unit Test Cases”. 

class SCC_COMMON:Testing:TestBase 

This is the base class which developers must extend in order to code their tests. The methods to be overridden 

are Setup(), Run(), and Teardown(). The system always calls these methods in that order for each test class. In 

the final phase of code execution, the system attempts to call Teardown(), even when there are errors. 

In addition, the system delivers helper methods for asserting various invariant conditions. The syntax is: Assert 

(&condition_which_must_be_true, "The expected condition was not met!"); In other words, the first argument 

to Assert() is a condition which you expect to be true. The second argument is an error message to display if 

the condition is not met. The other Assert*() methods are more of syntactic sugar. 

Summary: 

Property Summary: 

• public string FAILED 

• public string NOT_RUN 

• public string PASSED 

• public string status 

• public string UnitTestName 

Constructor Summary: 

Method Modifier and Return 

Type Method Name and Parameters Method Description 

public void TestBase(string UnitTestName_in) This is the constructor. Developers 

should pass in a test name as the sole 

argument. For now, the system does 

not use this value. 

Method Summary: 



Method Modifier and Return 

Type Method Name and Parameters Method Description 

public void Assert(boolean isTrue, string onFail) The first argument must be a boolean 

expression, which should evaluate 

to true. If false, the system throws 

an exception to indicate that the 

test failed. The system catches the 

exception, marks the test as having 

failed, and continues on to the next 

test. 

public void 

AssertNumbersDiffer(number num1, NA 

number num2, string onFail) 

public void 

AssertNumbersEqual(number num1, NA 

number num2, string onFail) 

public void 

AssertStringsDiffer(string str1, string NA 

str2, string onFail) 

public void 

AssertStringsEqual(string str1, string NA 

str2, string onFail) 

public void Msg(string msg) NA 

public void Run() This method must be overridden 

to implement the actual test that 

developers want to write. 

Warning! If you do not override this 

method, the system throws an error. 

public void Setup() The first method of the test class to be 

calledduringarun. 

public void Teardown() The last method of the test class to be 

called during a run. The framework 

tries to call this method even after an 

error. Due to inconsistent exception 

handling by the PeopleCode runtime, 

a PeopleCode "catch" statement does 

not catch all exceptions, and so the 

system cannot guarantee this method 

will be run after an error. Examples 

of untrappable errors include calls to 

the Error() builtin, SQL errors, and 

PeopleCode compile errors. 

Running Entity Unit Test Cases 

Access the Entity Unit Tester page (Set Up SACR, System Administration, Entity, Entity Unit Tester). 


Chapter 1 


Entity Unit Tester page 

This component is purely for running unit tests that you associate with entities on the Entity Unit Tests (setup) 

page. The unit tests themselves are based on the Campus Solutions delivered unit test framework. 

Note. Refer to the “Extending AAWS” section in the AAWS Developer’s Guide for more information about 

the Entity Registry page and how to create new entities. Also, refer to previous section “Creating a Unit Test”. 



First, an entity is selected. This will load the unit tests specified in the Entity Registry for that entity and all 

child entities in the grid below it. Except for the entity called ‘All’, the prompt dynamically marks with an * 

the entities that have no parent entity. Those can be considered top level entities. ALL is a special case as 

it will run unit tests for all entities in the registry. 

Example of an Entity Unit Tester page for a selected entity 

Once an entity is selected, any unit test for that entity or any children show up. If an entity has no unit 

tests, it will not be in the grid. 

Clicking Run Unit Tests will start running unit tests entity by entity. Each time all the unit tests for an entity 

are completed the status is returned and the next entity is set for running. This is all done automatically. 

The statuses will be set to either Passed or Failed. Passed telling you all the unit tests passed and Failed 

meaning at least one unit test failed. 

Warning! Once the unit tests start, wait until statuses are set for all unit tests. Changing pages and other such 

actions will interrupt the unit test process. 

Note. When unit tests are run from the entity registry page directly it will perform a similar process, however 

instead of doing it on a per entity basis it will be on a per unit test basis. 

To view the individual unit tests for an entity click the View Unit Tests link. 

Entity Unit Tests page 


Chapter 1 


Note. The fields are display only. Their setup is defined under Set Up SACR, System Administration, Entity, 

Entity Registry by clicking the View Unit Tests button for the desired entity. 

Active 

Type 

Application Class 

Last Run Status 

Last Run Datetime 

Details 

Specifies if the unit test is set to active and should be run. Any unit test set to 

not active will not be run. 

A categorical classification of the unit test, this is mostly for description. 

The application class of the unit test you created for this entity. 

The status the last time this unit test was run (Passed or Failed). 

The last time this unit test was run. 

Shows the details of the unit test, including all messages output. If a unit 

test fails, the information provided could help you identify the reasons 

of the failure. 

Entity Unit Test Details page 



Reviewing and Processing Staged Admission Transactions 

Use the Constituent Staging and Application Transactions components to review or edit the admissions 

transaction data stored in the staging tables. The staging tables are holding tables and are separate from the 

core production records. Any changes you make in the components posts to the core production records 

when the posting process is executed (real time or batch) depending on data update rules. You can use these 

componentstoreviewtheinformationstoredinthestaging tables at any time during the Processing Admission 

Transactions business process. For example, you might prefer to look at the transaction data immediately after 

the system loads it into the staging tables or after posting. This data is no longer editable once all transactions 

related to the constituent record have a transaction status of Posted or Cancelled. 

[ Bundle 21: A new field — Created By — has been added to all the pages of the Constituent Staging and 

Application Transactions components. The following note has been added to this chapter. ] 

Note. The Created By field has been added to all the pages of the Constituent Staging and Application 

Transactions components for Bundle 21. In this chapter, except for the following graphic titled Example of a 

Created By field, all the other graphics for these pages have not been updated for this change. 

Example of aCreatedByfield 

Correcting Admission Transaction Errors 

When a user saves or submits an application through AAWS or when you use File Parser to batch load an 

application, the system creates a transaction. A transaction might have an error status for the constituent 

(person) or the application record. For error indicators, look through both the components to find the 

corresponding field and enter a valid value. 

For example, suppose you selected the Manual Reconciliation option for Home Schools on the School Setup 

page. If the applicant has indicated that a school of attendance is a home school and submitted the application, 

the Application Transactions component displays an error message. 


Chapter 1 


Example of an error message in the Application Transactions component 

Toresolvesuchanerror,youcanclicktheEducationHistory tab, then select the valid external organization 

ID for the home-schooled applicant and finally click the Save button. 

Posting Admission Transactions 

After you have reviewed a transaction and corrected the errors, you can run the search/match/post process from 

the components itself by clicking the Run Search/Match/Post button. On clicking this button, you can run both 

processes at once: to search for matching people in your database and to post the transaction according to the 

Search/Match parameters you set up on the Transaction Setup component. The latter happens if Search/Match 

identifies an ID that needs to be created or updated or if the user has used a User ID already tied to an ID. 

In either way, the system uses the identified ID (EMPLID) to post the data. Alternatively, you can use the 

Constituent Staging and Application Transactions components to correct multiple transactions and then run the 

Transaction Management process to post the multiple transactions to the Campus Solutions database. 

If you have selected the Batch option on the Transaction Setup page, the system stores the transactions in 

staging tables and you will need to run the Transaction Management process to run Search/Match and post 

the transactions to Campus Solutions. However, if the system knows the EMPLID for the applicant, then 

the transaction is effectively treated as real time. 



Before running the Transaction Management process, set up the Search/Match parameters on the Transaction 

Management Process component. The Search/Match parameters that you define for the Transaction 

Management process overrides the Search/Match parameters set up on the Transaction Setup component. 

Regardless of how the post process is run, if it encounters any problems during processing, it will assign the 

record an application status of Saved Error or Submitted Error. Use the Constituent Staging and Application 

Transactions components to review these errors. 

Pages Used to Review and Process Staged Admission 

Transactions 


Summary Information SCC_STG_CONST_STG • Student Admissions, 

Application Transaction 

Mgmt, Constituent 

Staging, Summary 

Information 

• Campus Community, 



Staging, Summary 

Information 

Review the constituent 

status, and the error 

messages and transactions 

for the applicant. 

Run the search/match/post 

process or post the 

transaction data. Manually 

trigger Search/Match to 

review the list of matching 

candidates. 

Constituent Details SCC_STG_CONST_DTLS • Student Admissions, 



Staging, Constituent 

Details 




Staging, Constituent 

Details 

Participation Details SCC_STG_PARTICIP • Student Admissions, 



Staging, Participation 

Details 




Staging, Participation 

Details 

Additional Personal Info SCC_STG_ADDITION • Student Admissions, 



Staging, Additional 

Personal Info 




Staging, Additional 

Personal Info 

Review andeditthe 

applicant’s personal 

information in the staging 

record. An applicant’s 

personal information 

includes data such as date 

of birth, national ID, and 

address. 

Review and edit the 

applicant’s participation 

details in the staging 

record. An applicant’s 

participation details may 

include information such as 

work experience and honors 

and awards. 


applicant’s additional 

personal information in 

the staging record. An 

applicant’s additional 

personal information may 

include citizenship details 

and emergency contacts. 


Chapter 1 



Regional SCC_STG_REGIONAL • Student Admissions, 



Staging, Regional 




Staging, Regional 


applicant’s regional 

information in the staging 

record. 

Application Data SAD_APPL_STG • Student Admissions, 


Mgmt, Application 

Transactions, Application 

Data 

• Clickthelinkonthe 

Summary Information 

page. 

Education History SCC_EXT_ACAD_DATA • Student Admissions, 



Transactions, Education 

History 

• Click the link on the 


page and then click the 

Education History tab. 

Additional Academic Info SAD_STG_TEST • Student Admissions, 



Transactions, Additional 

Academic Info 

• Clickthe linkonthe 



Additional Academic 

Info tab. 

Review the error messages 

pertaining to the application 

in the staging record. 

In addition, review and edit 

the application program data 

and academic plan data. You 

can also review and edit 

the additional information 

regarding the application, 

such as application center, 

application fees, and 

recruiter assigned to the 

application. 

Review andeditthe 

education history pertaining 

to the application in the 

staging record. Education 

history includes information 

such as schools attended and 

degrees that are in progress 

or completed. 


additional academic 

information pertaining to the 

application in the staging 

record. Additional academic 

information includes test 

results and academic 

interests. 




Supplemental Information SAD_GENM_ATTACH • Student Admissions, 



Transactions, 

Supplemental Information 

• Click the link on the 



Supplemental Information 

tab. 


supplemental information 



Supplemental information 

includes general materials 

and file attachments. 

Application Regional SAD_APL_REG_STG • Student Admissions, 



Transactions, Application 

Regional 


country-specific data 



• Clickthe link on the 



Application Regional tab. 

Selection Parameters SCC_SL_SMP Student Admissions, 


Mgmt, Transaction 

Management Process, 

Selection Parameters 

Campus Community, 




Selection Parameters 

Enter selection parameters 

for running the Transaction 

Management process. You 

can run search match and 

post for saved and submitted 

transactions in the staging 

records. Also, you can 

process a transaction for a 

single person, all persons, or 

use Population Selection 

to select the persons in the 

staging records. 

Before you post the data, 

set up the Search/Match 

parameters on the 

Search/Match Parameters 

page. 

Search/Match Parameters SCC_SL_SMP_PARM Student Admissions, 





Campus Community, 





Set up your Search/Match 

parameters for the 

Transaction Management 

process. These are the rules 

that determine what the post 

processshoulddowiththe 

staging record after the 

Search/Match process is 

complete. 


Chapter 1 


Reviewing Applicant Error Messages and Transactions 

Access the Summary Information page (Student Admissions, Application Transaction Mgmt, Constituent 

Staging, Summary Information). 

Summary Information page 

Constituent Status 

Indicates the status of the constituent data in the staging table. This status 

controls when a transaction can be posted. Refer to the below table in the 

sub section titled Constituent Statuses for details. 

Note. Do not modify the delivered values in any way. Any modifications to 

these values require a substantial programming effort. 

ID 

Run Search/Match/Post 

 

Indicates the ID that will be used to post atransaction.IDvalueisdetermined 

either by the User ID that performs the transaction (in the case of returning 

users), the Search/Match process, or manually by an administrator if the search 

for duplicates was performed individually. 

Note that a returning user is a user ID that already has an EMPLID. 

Click to run Search/Match and if an ID is identified, post the constituent with 

the transactions that are listed in the Related Transactions section. 

If Search/Match has already been run, an ID is identified and the transaction 

status is Submitted, the system displays the Post Transaction Data button 

instead of the Run Search/Match/Post button. 

If all the transactions in the Related Transactions have a status of Posted the 

system disables the Post Transaction Data button. 

Click to access the Application Transactions component and view the 

admission application staged data. You can access the Application 

Transactions component only if you have access to the application center 

associated with the application transaction. 

Note. The link name, by default, matches the name given to the transaction 

on the Transaction Setup component. In the preceding exhibit example — 

Summary Information page — you can see that the link is Application Data 

because for the ADMISSIONS_APPLICATION transaction the Transaction 

Name is set to Application Data on the Transaction Setup component. 



Batch Trans (Batch 

Transaction) 

Search/Match Results 

Indicates whether this transaction is set as an online transaction or not on the 

Transaction Setup page. For example, if the transaction is generated because 

an applicant has saved an application through AAWS, the system does not 

select this check box. If the transaction is generated because you have loaded 

an application using the File Parser utility, the system selects this check box. 

Click to run Search/Match and manually review the matching candidates. If 

matches are found, the system displays the Integrated Search Results page 

after Search/Match has run. The Search/Match function uses the Search 

Parameter and the Search Result Code values related to the transaction, 

for which you clicked the Search/Match Results link. You specify the 

Search Parameter and the Search Result Code values for a transaction on 

the Transaction Setup component. 

Note. The system does not display the Search/Match Results link for a 

new user registration transaction. 

Set To Update ID 

Click this button if inadvertently you or the system has created or updated 

the constituent data to a wrong ID and you want to repost the data with 

the correct ID. 

The button appears only when Constituent Status = New ID Created or ID 

Updated and none of the transactions listed in the Related Transactions grid 

have a status = Posted (other than the new user registration transaction called 

ADMISSIONS_REGISTRATION). 

Note. If a transaction was posted with the wrong ID, you need to first unpost 

the transaction, delete the created transaction and then you will be able to 

see the Set to Update ID button and change the ID. You unpost a transaction 

from the Application Transactions component. 

Thepagedisplays the Constituent Errors section if the constituent status is Error. 

Application Center Security 

There are two ways to access the admission application transactions: 

• Campus Community menu path navigation (Campus Community, Constituent Transaction Mgmt, 

Constituent Staging) 

• Student Admissions menu path navigation (Student Admissions, Application Transaction Mgmt, 

Constituent Staging) 

If you use the Campus Community menu path navigation and if your user ID is not associated with a 

particular application center, you cannot access the application data associated with that application center. 

However, you can see how many applications exist for an applicant. In the following example, a user can 

see there is one application for the constituent. However, the user cannot view the application data because 

the link is disabled. The system has disabled the link because the user does not have 

access to the application center. 


Chapter 1 


Application Data link disabled for a user who does not have application center access 

If you use the Student Admissions menu path navigation and if your user ID is not associated with a particular 

application center, you cannot see how many applications associated with the application center exist. Also, 

you cannot view the application data associated with the application center. Therefore, the system strictly 

enforces the application center security for Student Admissions menu as compared to Campus Community 

menu where the security is not enforced. In the following example, a user cannot see whether there is an 

application transaction for the constituent because the user does not have access to the application center. 



Hidden search results for a user who does not have the application center access 

See PeopleSoft Enterprise Campus Solutions 9.0 Application Fundamentals PeopleBook - Update 1,“Securing 

Recruiting and Admissions”, Setting Security for Application Centers 

Constituent Statuses 

The following table describes the various constituent statuses: 

Loaded 

Constituent 

Status Description How Status is Set 

This status indicates that the system has loaded the data into the 

staging records and has not run Search/Match. 

Set by the system if 

Search/Match has not run 

or after an administrator 

corrects an error. 


Chapter 1 


Constituent 


New ID Created This status indicates that the system has run Search/Match and has 

created a new Employee ID for the staging record. 

Set by the system. 

The system assigns this status to a record when it adds a new 

Employee ID. It adds a new Employee ID when the Search/Match 

settings for the transaction determine that the record is new. The 

system also assigns this status to a record when you manually set 

the constituent status to Add New ID and then click the Run Search 

Match Post button or run the Transaction Management process. 

ID Updated 

Suspended 

Ignore 

The system can assign this status at any time during the process 

depending on how the transactions are set up. If you have selected 

the real time option on the Transaction Setup page, the status assigns 

this status when the user saves or submits the admission application. 

This status indicates that the system has run Search/Match and 

has found an existing Employee ID for the staging record or the 

transaction has been processed for a returning user where the 

Employee ID is known for the user. 

The system assigns this status to a record when it updates constituent 

data for an existing Employee ID. It updates an existing Employee 

ID when the Search/Match settings for the transaction determine 

that a matching record exists or if a returning user saves or submits 

a subsequent transaction. This can be done at any time during the 

process depending on how the transactions are set up. If the process 

is real time, it will be done at the point the user either saves or 

submits their application. 

This status indicates that the system has run Search/Match and has 

suspended the staging record for your review. 

The system suspends a record from further processing because 

possible matches have been found based on the Search/Match 

settings for the transaction. 

If previously you had changed the status from suspended to any 

other status, you can manually change the status back to suspended 

(depending on whether the constituent data has been posted to the 

production record). 

This status indicates that the system has run Search/Match and the 

Search/Match parameters setup suggests you to ignore the staging 

record. 

Processing of the record will not continue while this status is set. You 

can also manually assign this status if you want the system to ignore 

the staging record for further processing. 



Set manually. 


Set manually. 



Constituent 


Error 

This status indicates that the system has encountered a problem when 

processing the record. 


The system can assign this status to a staging record when it 

encounters a problem during data validation, when running 

Search/Match, or when the data is being posted. 

Add New ID 

Update ID 

Cancelled 

The system displays the error message on the Summary Information 

page. You must resolve the error and save the record. The system 

does not allow you to manually change from Error status to another 

status. When you resolve an error and save the record, the status 

automatically changes to Loaded, which indicates that you need to 

start the processing again by running the post process again (whether 

it is done by clicking the Run Search/Match/Post button or the Post 

Transaction Data button or by running the Transaction Management 

process). Notice that if an ID was already identified, the post process 

will use it to revalidate and to post the data. 

This status indicates that you have determined that the constituent 

should be added as a new person. 

You can assign this status when you have determined that the staging 

record should be added with a new Employee ID. 

This status indicates that you have determined that an existing 

constituent record should be updated with the staging record. 

You can use the Search/Match results or the ID field to choose the 

Employee ID whose record you want to update. After assigning this 

status and choosing an Employee ID, you can click the Run Search 

Match Post button or run the Transaction Management process to 

update the existing record. 

This status indicates that you have determined the transaction is 

incomplete, duplicate or should not be processed further. You cannot 

delete a transaction but you can cancel a constituent transaction. No 

further data updates by the user or the administrative user can be 

performed on a cancelled row. The Transaction Management process 

ignores the cancelled rows. 

Note. Cancelling a constituent implies that none of the transactions 

tied to it can be updated or processed further. 

Also if your user interface for the online transaction is configured 

appropriately, this status can be used when an end user has manually 

cancelled the transaction (for instance closed the browser window) 

before saving or submitting an admission application. 

Set manually. 

Set manually. 


Set manually. 

Reviewing Applicant Details 

Access the Constituent Details page (Student Admissions, Application Transaction Mgmt, Constituent 

Staging, Constituent Details). 


Chapter 1 


Constituent Details page (1 of 2) 

Constituent Details page (2 of 2) 



Reviewing Applicant Participation Details 

Access the Participation Details page (Student Admissions, Application Transaction Mgmt, Constituent 

Staging, Participation Details). 

Participation Details page (1 of 3) 


Chapter 1 






Reviewing Applicant’s Additional Personal Information 

Access the Additional Personal Info page (Student Admissions, Application Transaction Mgmt, Constituent 

Staging, Additional Personal Info). 


Chapter 1 


Additional Personal Info page (1 of 3) 






Chapter 1 


Reviewing Applicant’s Regional Information 

Access the Regional page (Student Admissions, Application Transaction Mgmt, Constituent Staging, 

Regional). 

Regional page (1 of 2) 



Regional page (2 of 2) 

Reviewing Application Error Messages and Application Data 

Access the Application Data page (Student Admissions, Application Transaction Mgmt, Application 

Transactions, Application Data). 


Chapter 1 


ApplicationDatapage(1of2) 



ApplicationDatapage(2of2) 

Set Status to Submitted 

This button only appears if the application status is Posted. 

If you have inadvertently posted the transaction data to a wrong ID, click the 

Set Status to Submitted button. On clicking the button, the system sets the 

application status back to submitted. For example, you may notice that an 

application was posted to a new ID but you should have created the application 

for an existing ID. To repost the application to the existing ID, perform 

the following steps: 

1. Run the Application Delete process to delete the application that you have 

posted to the wrong ID so that you do not maintain duplicate applications 

in the system. 

2. Click the Set Status to Submitted button and save the record. 

3. Click the Set to Update ID button on the Constituent Staging component 

and select the existing ID. 

4. Click the Run Search/Match/Post button to post the application. 

The following table describes the application statuses: 


Chapter 1 


Saved 

Application Status 

Description 

This status indicates that system has saved the admission application to the staging 

records and the application is not ready to be processed. 

The system automatically assigns this status when the online application calls 

the Save Application service operation. 

You can also manually set this status if you want to indicate that the application is 

not ready for processing. 

Submitted 

When setting up the File Mapping Definition, you can define the default value that 

File Parser should assign as the Application Status. 

This status indicates that system has submitted the admission application to the 

staging records and the application is ready to be processed. 

The system automatically assigns this status to an application when the online 

application calls the Submit Application service operation. 

You can manually set this status if you want to indicate that the application is 

ready for processing. You cannot post Saved transactions; only transactions with 

Submitted status can be posted. 

Saved Error 

Submit Error 

Pending 

Posted 

When setting up the File Mapping Definition, you can define the default value that 

File Parser should assign as the Application Status. 

This status indicates that the system encountered problems when saving an 

admission application. You must resolve these errors before the admission 

application can be posted. 

You cannot manually change this status. When you resolve the error and save the 

staging record, the system automatically sets the status back to Saved. 

This status indicates that the system encountered problems when submitting 

an admission application. You must resolve these errors before the admission 

application can be posted. 

You cannot manually change this status. When you resolve the error and save the 

staging record, the system automatically sets the status back to Submitted. 

This status indicates that manual reconciliation is required for some data element 

which is not necessarily an error. For example, when manual reconciliation is 

required for application fee waiver requests, the status is set to Pending and the 

application fee status is set to Waiver. You can manually change this status. 

This status indicates that the system has posted the data. The system runs the 

posting process when you click the Post Transaction Data button or the Run 

Search/Match/Post button, or when you run the Transaction Management process. 

The setup of the AAWS Application Fee and Waiver Processing group box on the Application Center Table 

page controls how an online application fee payment or waiver is processed. 

See: PeopleSoft Enterprise Recruiting and Admissions 9.0 PeopleBook, Building Your Recruiting Structure, 

Setting Up Your Recruiting Structure, Setting Up Application Processing Centers 

For information about how the payment is collected through third party hosted payment processing using 

Student Financials web services, refer to the following: 

See: PeopleSoft Enterprise Student Financials 9.0 PeopleBook, Using Student Financials Web Services for 

Hosted ePayment Transactions 

See: PeopleSoft Enterprise Campus Solutions 9.0 Admission Applications Web Services Developer’s Guide 

on My Oracle Support 



See: PeopleSoft Enterprise Campus Solutions 9.0 Admission Applications Web Services User’s Guide on 

My Oracle Support 

When payment is authorized, the Amount Sent to GL field is updated in the Application Transactions staging 

component (the field is not visible on the page) and is carried through to the core production Application 

Maintenance component (Application Items page). The Generate Direct to GL process uses the Amount 

Sent to GL value. 

See: PeopleSoft Enterprise Student Financials 9.0 PeopleBook, Using GL Interface Processing, Generating 

Direct to GL Entries 

The following documentation discusses how the Application Data staging page fields are updated when an 

online application fee or waiver is processed—based on the setup of the AAWS Application Fee and Waiver 

Processing group box on the Application Center Table page. 

The staging field SAD_APL_DAT_STG.APP_FEE_STATUS is not visible on the Application Data staging 

page. 

Processing Application Fees When Waiver Request is Not Allowed 

SCENARIO 1 

The Application Center Table setup is: 

• An application fee is required. 

• Payment is required when the application is submitted. 

• Waiver request is not allowed. 

When an applicant has completed all the required data for the online application and is ready to submit 

the application, the applicant clicks a payment button which triggers the AAWS Submit web service 

(SAD_SUBMITAPPL). The web service calls the Application Fee Calculation API which calculates the fee 

and returns the amount and currency to the external user interface which displays the fee to the applicant. 

The staging field SAD_APL_DAT_STG.APP_FEE_STATUS is set to Calculated. 

When the applicant successfully makes a payment, the application is submitted. The 

SAD_APL_DAT_STG.APPL_FEE_STATUS field is set to Received. 

The field values are carried through to the core production Application Maintenance component: 

ADM_APPL_DATA.APP_FEE_STATUS is set to Calculated and ADM_APPL_DATA.APPL_FEE_STATUS 

is set to Received. 

If the applicant does not successfully complete the payment process, the application remains in a saved status. 

SCENARIO 2 



• Pay later is allowed. 

• Waiver request is not allowed. 

If the applicant selects to pay now, the process is the same as scenario 1. 

If the applicant selects to pay later, SAD_APL_DAT_STG.APP_FEE_STATUS is set to Calculated and 

SAD_APL_DAT_STG.APPL_FEE_STATUS is set to Defer. 


Chapter 1 


These values are carried through to core production: ADM_APPL_DATA.APP_FEE_STATUS is set to 

Calculated and ADM_APPL_DATA.APPL_FEE_STATUS is set to Deferred. 

The Admissions office must follow up on fee payment. No other processing occurs in AAWS. 

Processing Application Fee Waivers in Staging 

SCENARIO 3 



• Payment is required when the application is submitted OR pay later is allowed. 

• Waiver request is allowed. 

• Manual reconciliation is required. 

If the applicant completes the payment, the process is the same as scenario 1. 

If the applicant requests a waiver, the applicant indicates the waiver basis (if required based on setup on 

Application Center Table page) and provides supporting documentation (optional - may be submitted by 

uploading an attachment or at a later time) and submits the application. 

Because Require Manual Reconciliation is selected as the Application Fee Waiver Process option on the 

Application Center Table page, then when the applicant submits the application, the staging fields are set 

as follows: 

• SAD_APL_DAT_STG. SAD_APPL_STS is set to Pending. 

• SAD_APL_DAT_STG.APPL_FEE_STATUS is set to Waiver. 

• SAD_APL_DAT_STG.WAIVED_AMT is set to blank. 

• SAD_APL_DAT_STG.APP_FEE_STATUS is set to Pending. 

The administrator reviews supporting documentation (Supplemental Information page) and grants or denies 

the waiver. 

If the waiver is granted, the staging fields are updated as follows: 

• The administrator changes the staging Application Fee Status value to Waived. 

• Programmatically, SAD_APL_DAT_STG. SAD_APPL_STS is set to Submitted. 

• SAD_APL_DAT_STG.WAIVED_AMT shows the waiver amount. 

• SAD_APL_DAT_STG.APP_FEE_STATUS is set to Calculated. 

These values are carried through to core production Admissions tables: 

• On the Application Data - Application Fees page, the Fee Status value is Waived, the Waive Amount value 

appears, and the Waiver Basis Code value appears based on the value in the related staging field. 

• On the Application Data page, the value in the Status field in the Application Fee Information group 

box is Calculated. 

If the waiver is denied, the administrator sets the Application Fee Status to Pending and the Application 

Status is automatically set to Saved. The administrator must manually notify the applicant that the waiver 

request is denied. 



Processing Application Fee Waivers in Core Admissions 

SCENARIO 4 



• Payment is required when the application is submitted OR pay later is allowed. 

• Waiver request is allowed. 

• Application can be posted to core production before waiver request is determined. 

If the applicant completes the payment, the process is the same as scenario 1. 

If the applicant selects to pay later, the process is the same as scenario 2. The Admissions office must follow 

up on fee payment or waiver. No other processing occurs in AAWS. 

If the applicant requests a waiver, the applicant indicates the waiver basis (if required based on setup on 

Application Center Table page) and provides supporting documentation (optional - may be submitted by 

uploading an attachment or at a later time) and submits the application. 

If Allow to Post is selected as the Application Fee Waiver Process option and the App Fee Status Waived 

option is selected on the Application Center Table page, then when the applicant submits the application, the 

staging fields aresetasfollows: 

• SAD_APL_DAT_STG.APPL_FEE_STATUS is set to Waived. 


• SAD_APL_DAT_STG.APP_FEE_STATUS is set to Calculated. 


• On the Application Data - Application Fees page, the Fee Status value is Waived, the Waive Amount value 

is blank and the Waiver Basis Code value appears based on the value in the related staging field. 


box is Calculated. 

The App Fee Status Waived option could be used by schools who allow waivers but automatically grant the 

waiver without review or assessment. 

If Allow to Post is selected as the Application Fee Waiver Process option and the App Fee Status Waiver 

Request option is selected on the Application Center Table page, then when the applicant submits the 

application, the staging fields are set as follows: 

• SAD_APL_DAT_STG.APPL_FEE_STATUS is set to Waiver. 


• SAD_APL_DAT_STG.APP_FEE_STATUS is set to Pending. 


• On the Application Data - Application Fees page, the Fee Status value is Waiver, the Waive Amount value 

is blank and the Waiver Basis Code value appears based on the value in the related staging field. 


box is Pending. 

Waiver requests must be assessed using the core production Application Maintenance component. 


Chapter 1 


Query adm_appl_data.appl_fee_status to find the applicants with waiver requests. 

Reviewing Applicant’s Education History 

Access the Education History page (Student Admissions, Application Transaction Mgmt, Application 

Transactions, Education History). 

Education History page (1 of 3) 






Chapter 1 


Reviewing Additional Academic Information 

Access the Additional Academic Info page (Student Admissions, Application Transaction Mgmt, Application 

Transactions, Additional Academic Info). 

Additional Academic Info page 

Reviewing General Materials and Attachments 

Access the Supplemental Information page (Student Admissions, Application Transaction Mgmt, Application 

Transactions, Supplemental Information). 



Supplemental Information page 

Reviewing Application Regional Information 

Access the Application Regional page (Student Admissions, Application Transaction Mgmt, Application 

Transactions, Application Regional). 


Chapter 1 


Application Regional page: Australia 

The system displays this page only if the country-specific options are selected on the SA Features and 

Academic Institution 6 pages. 

See Also 

PeopleSoft Enterprise Campus Solutions 9.0 Application Fundamentals PeopleBook - Update 1, “Reviewing 

Installation Setup and System Defaults”, Selecting Student Administration Installation Options 

PeopleSoft Enterprise Campus Solutions 9.0 Application Fundamentals PeopleBook - Update 1, "Designing 

Your Academic Structure," (AUS, CAN, GBR, NZL, NLD) Activating Other Student Administration Features 

Updating and Posting Transactions in Batch 

Access the Selection Parameters page (Student Admissions, Application Transaction Mgmt, Transaction 

Management Process, Selection Parameters). 



Selection Parameters page 

Use this functionality to process temporary constituent IDs stored inside the constituent and the transaction 

staging tables. You can process all IDs, just one at a time or use Population Selection to select staged IDs 

meeting custom criteria. You can decide to only process the saved transactions, the submitted transactions or a 

combination of both. The process allows you to change the transaction (application) status from Saved to 

Submitted, run Search/Match and once an EMPLID is identified, post the constituent and transaction data to 

production tables. The Transaction Management process does not process IDs with a Constituent Status set to 

Cancelled or for which their transaction is already Posted. It also does not run the Search/Match process when 

an EMPLID is already identified or the Constituent Status is set to Ignored, Suspended, orError. Whenan 

ID is set to be suspended, only manual intervention performed from the Constituent Summary page can be 

done to reset the status to something else after evaluation. For instance, a self-service user submits an online 

application. Search/Match found one exact match and the transaction was set up to suspend the constituent 

if this condition is encountered. The suspended record requires manual intervention by the administrative 

user to validate the matching candidate found should be updated or not. 

Transaction Name 

Select the transaction for which you want to process the constituent and their 

transactions (applications). 

ID Selection 

ID Selection 

Select one of these values: 

• One Person Temporary ID: Select to run the process for a single person 

(constituent) in the staging record who is associated with the selected 

transaction name. 

• All Person Temporary IDs: Select to run the process for all the persons in 

the staging record who are associated with the selected transaction name. 


Chapter 1 


• Population Selection: Select if you want to use the population selection 

process for selecting the temporary IDs who are associated with the 

selected transaction name. 

Temporary ID 

Process Submitted 

Transactions 

Process Saved Transactions 

Available only when the ID Selection is One Person Temporary ID. Youmust 

enter the specific temporary constituent ID to process here. 

Select if you want the system to process transactions that have an application 

status of Submitted. When you select this option, the Submitted Transactions 

box appears. 

Select if you want the system to process transactions that have an application 

status of Saved. When you select this option, the Saved Transactions box 

appears. 

The system posts only submitted transactions to the database. 

Submitted Transactions 

This group box appears only when the Process Submitted Transactions option is selected. 

RunSearchMatch 

Post Transaction Data 

Select to run Search/Match for the Submitted transactions. 

Select to post the Submitted transactions. 

Note. When processing submitted transactions, the component forces you to select both check boxes. This is 

to ensure that you are not introducing duplicates into your database. If an ID is already identified, the process 

skips Search/Match and proceeds to validate and post the transaction data. 

Saved Transactions 

This group box appears only when the Process Saved Transactions option is selected. 

Update Status to Submitted 

RunSearchMatch 

Post Transaction Data 

Select to change the application status from Saved to Submitted. 

Select to run Search/Match for the saved transactions. If the process identifies 

that a new ID needs to be created or an existing ID needs to be updated, the 

constituent data is posted. 

When an EMPLID is already known to the system, Search/Match is not 

invoked by the process. 

Select to post the transactions (applications). Only submitted transactions for 

which you have run Search/Match can be posted. Therefore, to be able to 

select this check box, you must select the Update Status to Submitted and the 

Run Search Match check boxes. If you select all the three check boxes, the 

Transaction Management process will first change the status to Submitted,then 

it runs Search/Match and finally depending on the Search/Match parameters 

it posts the transactions. 

Population Selection 

This group box appears only when the ID Selection of Population Selection is selected. 



Population selection is a method for selecting the IDs to process for a specific transaction. Selection tools are 

available based on the selection tools that your institution selected in the setup of the Population Selection 

process for the Transaction Management process and on your user security. Fields in the group box appear 

based on the selection tool that you select. If your institution uses a specific delivered selection tool (PS Query, 

Equation Engine equation, or external file) to identify IDs for a specific transaction, you must use it. 

See PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook, Using the Population Selection 

Process 

Specifying Search/Match Parameters for Batch Processing 

Access the Search/Match Parameters page (Student Admissions, Application Transaction Mgmt, Transaction 

Management Process, Search/Match Parameters). 

Search/Match Parameters page 

Use this page to set up your Search/Match parameters. These are the rules that determine what the post 

process should do with the staging record after the Search/Matchprocessiscomplete.Thefieldsonthispage 

are similar to the Search/Match Setup page (Set Up SACR, System Administration, Utilities, Constituent 

Transaction Mgmt, Transaction Setup, Search/Match Setup).

Managing PeopleSoft Admission Transactions - Lee College

Create successful ePaper yourself

Delete template?

Save as template?