Configuring Your Programs for Ease of Data Integration
Data integration starts as soon as you start collecting information from your applicants. While much of a CAS application is uniform and shared by participating schools, you have control over how your programs are configured on the application. You can make decisions in the program configuration stage that will make it easier to integrate the data later on. We'll consider ways to configure your programs that will make the three major steps in a data integration easier: extracting data, transforming data, and loading data.
Simplifying Exports: Custom Requirements
When configuring your programs, you have the option to set the requirements specific to applicants to your program. You can ask additional questions of your applicants, like essays, residency status, choice of concentration, etc. And you can ask applicants to upload additional documents, like resumes, personal statements, etc. Keeping the following things in mind when configuring custom requirements for your programs will make it easier to build a data integration later.
Avoid Redundancy
Before adding a custom requirement, such as a question or document request, double-check that the shared part of the CAS application (quadrants 1 through 3) doesn't already require it. For example, if all applicants to the CAS are required to upload a resume, it wouldn't make a lot of sense to ask for a resume again to apply to your program. Similarly, if all of a CAS's applicants are asked about their visa status, it would be redundant to ask again in your program's fourth quadrant. Requirements at the CAS level will be shared across all applicants to all of your programs, and will likely be shared with applicants to your programs in other CASs. This uniformity will make it easier to integrate data for applicants to different programs and CASs.
Stick to the Essentials
Before adding any custom requirement, such as a question or document request, be very sure that it is absolutely necessary to ask it of your applicants. Collecting additional data and/or documents that won't be used can lead to a bloated and overly complex data integration that doesn't serve a purpose. In other words, cluttering up your data integration with nonessential information may interfere with the transfer of essential information. Good justifications for adding custom requirements include: (a) the requirement supports an essential business process like application review and (b) the requirement supports an essential reporting requirement like a report to your accrediting body.
Organization-level Questions
For the custom questions that you do create, use organization-level questions wherever possible. Organization-level questions are custom questions that are asked to all applicants to any of your programs. Unlike program-level questions, which are asked only of applicants to individual programs, organization-level programs will be exported uniformly for all applicants. For example, if you ask "Are you a resident of Massachusetts?" as a program-level question and you have 10 programs, there will be 10 different fields containing residency information that you'll have to deal with when building your data integration; if, on the other hand, you ask the same question as an organization-level question, there will be just 1 field containing residency information across applicants to all 10 of your programs.
When creating custom questions for the fourth quadrant, ask yourself, "What questions can we ask all applicants?" Some questions will be obvious candidates for organization-level questions, while others will not. For example, a question asking for an applicant's student ID (relevant for alumni) would make sense as an organization-level question, while a question about specific program-prerequisites would not. A question that's required of applicants to some, but not all of your programs could function well as an organization-level question if it won't cause much confusion for those applicants where it isn't relevant. For example, asking about concentration for all applicants when only some of your programs have concentrations would make it easier to integrate concentration choice data, but might confuse some of your applicants.
Avoiding Transformations: Store Local System Values in Configurable Fields
When configuring your programs, you have access to several configurable fields that you can use to make it easier to load CAS applicant data to your local systems. Using these fields to store values that your local system already uses will allow you to avoid transforming some of your data to match local system requirements.
Program Information
You can configure the applicant-facing name, WebAdMIT name (a.k.a., "designation label"), level, track, and delivery for each of your programs. These fields contain a lot of important information about your applications, and you should use them to make it easy to integrate into your local systems. In general, you should store values that your local system uses already in these fields. For example, you can store the specific program code used by your local system in the WebAdMIT Label field; when you load application data, you can use that field to load the exact value that your local system expects for the program code.
Custom Questions
When configuring your fourth quadrant custom questions, you can add custom export codes to your response options. Using the local system values in these export codes will make it much easier to load your applicants' responses to these questions to your local systems. For example, if the favorite color is stored in your local system as "B," "R," or "Y," you would configure your custom question responses to have export codes matching those local system values. Review additional guidance on configuring export codes in custom questions.
Streamlining Uploads: Standardizing Your Designations
Taking a consistent approach to configuring your programs will make it easier to build your data integration. There are a lot of choices to make when building your designations; we'll focus on a few that are especially significant in data integrations.
Start Term
You can configure programs in several ways to collect your applicants' desired start terms. In the fixed start term approach, you configure a separate designation for each program's possible start term (e.g., "Mechanical Engineering - Fall" and "Mechanical Engineering - Spring"). The alternative flexible start term approach involves configuring a single designation per program with a "Rolling" start term and then collecting the desired start term with a custom question in the fourth quadrant. To make data integration easier, we recommend being consistent with your approach: either all designations have a flexible starting term or all designations have a fixed starting term. If you decide to go with flexible start terms, an organization-level custom question will make it significantly easier to integrate this important piece of information into your local system (see above for more information).
Special Applicant Types: International, Alumni
To accommodate special applicant types with significantly different requirements, fees, and deadlines, you can either configure separate designations or use a single designation and configure rules to assign the appropriate settings. The challenge to data integration is clearly and uniformly identifying the relevant special characteristic. For example, creating a separate designation for alumni of your institution to apply to in order to give them reduced fees and requirements might make it difficult to accurately identify those applicants as alumni since the fact of their being alumni is only recorded in the program information itself. Using fourth quadrant custom questions or the Extended Profile to collect these unique applicant characteristics will make it easier to integrate them into your local systems.