Setting Up CTM (Defining Transactions and Data Update Rules) and Configuring the Admission Transactions (Application Configuration component)

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 Campus Community Fundamentals: New User Registration and CTM

See Campus Community Fundamentals: 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.