Handling Multiple Applications per Applicant in WebAdMIT

Last updated
Save as PDF

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.

Approaches

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.

Approach	Description	Pros	Cons
Collect – WebAdMIT	Change the CAS application configuration to prevent applicants from submitting more than one application per cycle	Eliminates multiple application problem	Reduces number of apps
Extract – WebAdMIT	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
Transform – Software Development	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
Load – Local Systems	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 a member of your account team 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 before 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.