Return to Navigation

Understanding Admission Transactions Setups

You define admission transactions using CTM pages. Then, you use the Application Configuration component to configure the admission transactions.

Before you deploy AAWS or start loading the applications, you must define the admission transactions through the CTM setup pages. For AAWS, define a transaction for the online application that a user saves or submits through the Save Application or Submit Application service operations. If you want to load admission applications using the PeopleSoft File Parser utility, define an offline transaction for the batch load.

The default transaction definition for AAWS that is delivered with the system is: ADMISSIONS_APPLICATION (online application transaction).

Additionally, if you have defined an online transaction for the online application, consider using the New User Registration framework to allow a guest or a returning user to access your system. The framework delivers a sample login page that contains all the security objects delivered as part of the framework. The New User Registration framework is also a consumer of the CTM framework and delivered with your system is the CTM transaction code called NEW_USER_REGISTRATION. The New User Registration framework, using the New User Registration Context, can also transfer the newly authenticated user to the self-service page you created for your online application.

See New User Registration and CTM

See Understanding New User Registration

Warning! The ADMISSIONS_APPLICATION transaction is delivered only as a reference. It is not required that you use this transaction.

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 transaction you may define.

Root Package ID

Path

Application Class ID

SCC_OLA

TRANSACTION

AdmissionTransaction

The staging record delivered with ADMISSIONS_APPLICATION is SAD_APL_DAT_STG. This record stores the transaction status and transaction status date value for ADMISSIONS_APPLICATION. Do not change this value. You should always use this value when defining any new application transaction you may define.

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

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.

While you can use the same AAWS online user interface for all your academic careers and institutions, you can configure the admission transactions to behave differently. For AAWS and bulk load using File Parser, 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 CTM. 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. After defining the admission CTM transactions, use the Application Configuration component to set up different combinations of institutions and careers and map each institution-career combination to a defined admission transaction (CTM Transaction Code).

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.

To be consistent with existing processes that update this data, the application data update rules are as follows for the following entities:

Entity

Rules

Academic Interests

If data exists on ADM_INTRST_HDR for an existing EMPLID and ACAD_CAREER and the max ADM_INTRST_HDR.EFFDT is not equal to %Date, a new row is inserted with EFFDT = %Date. Rows are inserted into ADM_INTERESTS for each academic interest populated on SCC_STG_ADMINT. PRIORITY is populated based on ADM_INTRST_HDR.USE_PRIORITY.

If data exists on ADM_INTRST_HDR for an existing EMPLID and ACAD_CAREER and the max ADM_INTRST_HDR.EFFDT is equal to %Date, a row is not inserted into ADM_INTRST_HDR. Rows are inserted into ADM_INTERESTS only where SCC_STG_ADMINT.EXT_SUBJECT_AREA does not exist on ADM_INTERESTS for the current effective date. If ADM_INTRST_HDR.USE_PRIORITY is ‘Y’, the max ADM_INTEREST.PRIORITY is determined and incremented to the next number when new rows are inserted.

External Academic Data

A new Data Number (EXT_DATA_NBR) is inserted to EXT_ACAD_DATA if the EXT_ORG_ID on the staging record SCC_STG_ACADHST exists on the core record ACAD_HISTORY. The max EXT_DATA_NBR existing on EXT_ACAD_DATA is determined and incremented to the next number on insert.

All child records are populated with the same EXT_DATA_NBR that is inserted on EXT_ACAD_DATA if the field exists on the child record.

Exception: For the record EXT_DEGREE, if data exists on EXT_DEGREE where DESCR, DEGREE_DT, DEGREE_STATUS and LS_DATA_SOURCE = data from staging record (SCC_STG_EXTDEGR), a new row is not inserted.

General Materials

A new record is always inserted.

The max GENL_MATL_NBR is determined and new incremented to the next number when new rows are inserted.

Residency Official and Residency Appeal

If the keys (INSTITUTION, ACAD_CAREER and EFFECTIVE_TERM) do not exist on RESIDENCY_OFF or RESIDENCY_APEAL, a new row is inserted.

If the keys exist, a new row is not inserted and the data is not updated.

Residency Self (Self Reported Residency)

If Date Reported (SCC_STG_RES_SLF.SELF_REPORT_DT) does not exists on RESIDENCY_SELF, a new row is inserted.

If Date Reported (SCC_STG_RES_SLF.SELF_REPORT_DT) exists, a new row is not inserted and the data is not updated.

Test Score

If SCC_STG_TEST.TEST_ID does not exist on STDNT_TEST for the EMPLID, a new row is inserted along with any child rows (STDNT_TEST_COMP).

If the following elements on STDNT_TEST_COMP match the elements on the staging record SCC_STG_TESTCMP, update Score, Percentile and Date Loaded regardless of the previous score reported: EMPLID, TEST_ID, TEST_COMP, TEST_DT and DATA_SOURCE.

If there is not an existing row on STDNT_TEST_COMP that matches on EMPLID, TEST_ID, TEST_COMP, TEST_DT, DATA_SOURCE, a new row is inserted.

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 definition 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.

For offline transactions, you must enter the transaction code as a default value for the file mapping definition (Campus Community File Parser setup). The system uses this mapping to identify which transaction definition to use when it receives an application through the File Parser.