In some CASs, applicants can submit multiple applications to the same institution in the same cycle. For example, an applicant might apply to both the Computer Engineering and the Cybersecurity programs at the same university. This is great for the institution - the more applicants there are, the more likely the institution is to find right-fit students. Dealing with integrating data in this situation can be challenging. WebAdMIT Lists and Exports are based on the applicant and not individual applications. An applicant with more than one application is exported as a single row; each application gets its own set of columns relating to the "designation" fields. Some systems can accommodate data in this format: multiple columns in a single row can be loaded to multiple records. If you're working with a system like this, you won't need the information below. But other systems can't deal with data in this format: a single row can only be loaded to a single record. This article is intended to provide an overview of the possible approaches you can take to overcome this obstacle.
Solving the problem of WebAdMIT exporting multiple applications in a single row can be tackled in several ways.
|Location of Change||Collect||Extract||Transform||Load|
|WebAdMIT||Prevent applicants from submitting multiple applications||Unchanged||Unchanged||Unchanged|
|WebAdMIT||Unchanged||Change the way data is extracted from WebAdMIT||Unchanged||Unchanged|
|Software Development||Unchanged||Unchanged||Change the format of the data after extracting and before loading||Unchanged|
|Local Systems||Unchanged||Unchanged||Unchanged||Change the way data is loaded to local systems|
Here are the possible approaches spelled out more clearly with some advantages and disadvantages.
|Change the CAS application configuration to prevent applicants from submitting more than one application per cycle||Eliminates multiple application problem||Reduces number of apps|
|Create one user per program with access to only that program's applicants||Eliminates multiple application problem||User creation work; more export files to deal with|
|Create a new file pivoting the "designation" fields so that there's one row per application instead of one row per applicant||Allows multiple apps; no additional users in WebAdMIT||Requires software development|
|Configure several loads for the same file format, loading one set of "designation" fields with each load configuration||Allows multiple apps; no additional users in WebAdMIT; no software development||Have to configure multiple loads|
Let's review each approach in more detail.
Collect - WebAdMIT
In some CASs, you have control over whether to allow applicants to submit multiple applications. Check with your Account Manager if you're not sure what the situation is in your CAS. Adjusting this setting to allow only one application per applicant per cycle will eliminate the problem of multiple applications entirely. The downside to this option is that you may receive fewer applications overall.
Extract - WebAdMIT
If you want to continue allowing applicants to submit multiple applications, you can consider taking steps to ensure that when you export data from WebAdMIT, each row in the export will have data for a single application. You can accomplish this through user permissions. A WebAdMIT user with access to applicants to only a single program can't export data for applications to other programs. For example, if an applicant has applied to the electrical engineering program and cybersecurity program and a user with only access to the cybersecurity program's application exports that applicant's data from WebAdMIT, only the cybersecurity application data will be exported. With this approach, you'll need a different user for each distinct program. Lists and Exports, as long as they have been made visible to everyone, will be accessible to all of these users, so you'll be able to maintain a single set of List/Export combinations. If you are automating the retrieval of data with the WebAdMIT API, you will have to make a separate call for each of these users to retrieve all of the data. This approach involves extra work: user creation, multiple API calls. You'll also have to add a user each time you a program, and account for that change in any API call scripts. But it allows you to continue to collect multiple applications per applicant and it doesn't require any change to how you transform and load the data to your local systems.
Transform - Software Development
If you don't want to add extra users to WebAdMIT, you can take the data as-is and manipulate it prior to loading to your local systems. The goal with this approach is to produce a file where each row represents a single application instead of a single applicant as it does when it comes out of WebAdMIT. Some software development can accomplish this goal. Thankfully, the "designation" fields are exported in a predictable, orderly fashion. You can line up all of the information about each application using the suffixes on the "designation" fields. For example, the "designation_0" and the "designation_track_0" columns will have information about the same application. Pivot the "designation" fields in the original file so that there is one set of matching suffixes per row. For example, an applicant with two applications will have two rows: one with all of the values in the "designation…_0" fields and the other with all of the values in the "designation…_1" fields. The "designation" fields are identical across applications, so you can condense the multiple columns to a single set of columns. All other columns in the WebAdMIT export should be replicated for each application because they apply to the applicant and not any individual application. Be sure that your code can accommodate any number of "designation" column sets. While this approach requires additional software development, it has the advantage of allowing multiple applications per applicant, eliminating additional work in WebAdMIT, and avoiding the need to change how data is loaded to local systems.
Load - Local Systems
If you don't have the software development resources to transform the standard WebAdMIT file format, but do have access to configure the tool that loads data to your local systems, you can try this approach. Your load configuration tool must be versatile to allow for this approach: you have to have the ability to ignore source fields when loading data to local systems. Configure a different load for each possible set of "designation" fields you expect (the number of applications a single applicant might submit in a given cycle). Each load will be identical for all fields except the "designation" fields. Each load will load only one set of "designation" fields - use the suffix ("…_0", "…_1", etc.) to identify sets. This approach requires extra work when configuring the loads to your local systems. It has the advantage of requiring no additional software development or WebAdMIT work, and it allows applicants to submit multiple applications.