It's common to source applications for platforms outside Element451, or import historic applications to Element451 for a complete picture of student engagement. Application data can be imported to Element451 to appear the same as Application data generated by Element's Application module. Data will appear in the Application card of the contact's Profile. This data can then be used for engagement or transfered to the Decisions module and reviewed.

There are a specific set of fields that must be mapped in the Import Task to make it look like the student applied directly in Element451, and a number of modules you must configure to use this data as if were native to the platform.

Need help creating an import task? Start with Creating Imports and then come back to this article make sure you aren't missing any fields.

When importing applications, you can map as many fields as you want, but there are a few required fields to make sure these applications display correctly on the student profile and in the Decisions feature.

The following fields are required:

The import file might only have one column for major, but need to map it into several milestone and application fields. This is where calculated columns will come in handy, especially DB_MAP or DS_MAP.

In this example, major is in column 15. Column 15 is mapped to

See an example using Application Term.

Learn more about Calculated Fields.

Most import files will not have application status values that are compatible with Element451's options, "started", "completed", and "submitted".

Some import files might have statuses like "in review", "interview" or "admitted". This will not be compatible with Element451's application status and must be imported as a Decision status.

Use a calculated column to manually enter the value. In most cases, all students being imported have submitted the application, you can simply put "submitted" (all lowercase and with double quotes) into the formula screen.

When mapping the fields mentioned above, scopes will need to be set up for all application fields. If you click the more button and Settings this is where we map the application fields to a specific application in Element451.

For example, if you are importing graduate applications, you would select your graduate application you created in Element451. In addition to selecting an application, you will need to set up the transformations. More information on mapping fields on import can be found our Column Setting Options for Imports.

Creating a new Application for imported applications is a helpful way to distinguish them from applications submitted via Element451. For example, when importing historic applications, create a "Historic Applications" application in Element. Or, when importing Common App, create "Common App" application. These new Applications, or application "types", will appear in-line when viewing the "All Applications" screen. These new applications can be created by duplicating another application, and can be left Inactive.

Even though student's won't be interacting with this application type directly, it is still best practice to add steps and fields that correspond to the fields being imported, for both application-related data and demographic data about the student. Imported apps will still generate a PDF copy of the app data, and the PDF will be formatted according to the application's steps and fields.

Element451 saves Application data as an attribute of the contact, but Decisions are stored separate. Import tasks will create an Application that is visible on the contact Profile, but will not create a Decision from that Application data by default.

If imported applications have a submitted status, a Rule can "Register" the Application as a Decision. This will create a Decision from the Application data that will be visible in the Decisions module. The Decision can then be reviewed and released as if it originated in Element451.

Follow these steps to create the Decision registration process:

Create a label

Map it in the import (user-labels-import) so everyone from the import gets a label added to their profile. It can be named something like "Imported App to Decisions" or get specific and say "Common App Application". When creating the label, you will want to copy the taxonomy code for it, add a calculated column to your import and put the taxonomy in the formula field between double quotes, similar to the Application Status set up.

Create a Rule

The step uses the Register Application in Decisions action and select the application name. Your trigger will be User Label Added trigger. Set it active and you are good to run your application import!

Data from application platforms or historic application systems often have multiple applications per student. While a student's application data may be unique per row, their identifying information would be duplicated across multiple rows. We call this "repeating on" application.

Element451's Import Tasks require the import file to "repeat on" the contact, where each student's identifying information (email, school ID, etc) only appears in one row per file. A file that repeats on application may be ingested by the Import Task but subsequent rows where the same student appears will overwrite previous rows. Thus, only one application will be imported.

There are two options for importing multiple applications:

This is usually done by term. For example, one import file with Fall 2024 applications, another with Spring 2025 applications and so on. Each file will require it's own Import Task.

Use star mappings to scope each application mapping to application type and term, where term corresponds to the file being imported.

This can also be done per contact, where the files are separated not by term, but by order. The student's first application in file one, second in file two and so on. Star mappings would also be used here, but scoped to type and position (ie. 1 for file one, 2 for file two, etc).

In this scenario, the student's first application major, term and degree are in columns 15-17 for example. Then their second application is in columns 18-20, and so on. This "flattens" the file to repeat on one row per contact.

Use star mappings and scope by application type and position, with the first set of columns scoped to position 1, the second to position 2 and so on.

In an import file that contained three applications, three columns would contain the application major. Map these columns to user-applications-major-* and under the scope settings of each field, indicate the position it is going into: Application 1 Major scopes to position 1.

Element451 saves application data as an attribute of the contact, but Decisions are stored separate. Import Tasks can only import contact data, so decision-specific data cannot be imported. This distinction is also why it is necessary to register the application as a decision with a Rule. Learn more about the Element451 data model.

Importing Decision-related data involves a mix of Custom Fields and Intelligent Admissions Rules, but the resulting process will function automatically.

Custom Fields are an attribute of the contact, but will be used by Decision automations to populate the corresponding attributes of the Decision. The Decision automation will run almost immediately after the Decision is created. These Custom Fields can thought of as a temporary holding space for the data; it is usually fine for the Custom Field to be overwritten by subsequent imports if needed.

Decision Statuses define the student's journey from application submit to decision release. Decision reviewers will typically update the status as the review progresses.

The import file should have one column for the decision status and each row should store the code or name of the status.

Checklist for Importing Decision Statuses:

Decision Checklist items track the requirements of a Decision, such as receiving a transcript, receiving a letter of recommendation or verifying test scores. Checklist Items as stored as a boolean, "checked" or "unchecked".

The import file should have one column for each checklist item and each row should store the value as a boolean or code. Multiple codes will need to be condensed to true or false values either in a calculated column of the import or via the Checklist item condition.

Checklist for Importing Checklists:

Decision Criteria score a Decision for various purposes, such as test scores, GPA or interview. Scores as stored as a number and can be assigned globally (one per Decision) or per Decision reviewer.

The import file should have one column for each criteria and each row should store the score as a code or number.

Checklist for Importing Criteria:

Each application import has different requirements as explored above, and understanding the complete process can be difficult. The sequence below outline of the most robust process:

Steps 1 - 7 of this process are manual, and 8-11 will happen automatically.

Once built, this process is repeatable for multiple files as needed, and can even be used for multiple applications from the same student.