Skip to main content
* (star) Mappings

Learn how to use Import + Export mappings that end in a asterisk.

Timothy Davis avatar
Written by Timothy Davis
Updated over a week ago

What are "Star" Mappings?

"Star" mappings are any column mapping option in the Imports + Exports module that ends in an asterisk, *. We call them star mappings for fun 🌟

The star indicates that you can "scope" the mapping to a given object in the repeater that the mapping targets.

..what..? What is a scope? What's a repeater? Let's dive in.

Understanding the Element451 Data Model

To best use star mappings, we must first understand how Element451 stores data, and how that data is accessed by mappings.

Make sure you're familiar with Element451's Data Model, specifically repeaters and Import+Export Mappings, before continuing.

What are Scopes?

Scopes tell mappings which repeater to target.

Sticking with our example of user-applications-major, from the Element451 Data Model article. This mapping asks for one scope, the application "type". This corresponds to the "app_type" attribute in the example above.

By declaring the Application scope, the user-applications-major will match the first application object that matches that "app_type" attribute.

{
registration_id: "849F3PO",
app_type: "Incoming Freshman"
major: "Dancing",
term: "Fall",
student_type: "Freshman",
index_weight: 1
},

But what if two applications have the same type? What if two apps both have "Incoming Freshman" as the app_type?

We need to be able to match on more properties of the application. Thus, we have star mapping.

When using the user-applications-major-* field, we're now able to match on one or more properties of the application. The system will match to the first application object that matches all scopes.

Scope Options

Star mappings offer one or more scoping options.

  • Type: indicating the type of the target object (application type, milestone type, test type)

  • Position: indicating the position of the target object in it's repeater array. Denoted by the index_weight property.

  • Term: indicating the term that an application is for. Available for user-applications-... star mappings

  • Major: indicating the major that an application is for. Available for user-applications-... star mappings

  • ZIP Code: Available for user-school-... and user-address-... star mappings.

  • Registration ID: Available for user-applications-... star mappings.

Repeaters with Star Mappings

The following repeaters have star mapping options:

  • user-addresses-...

  • user-applications-...

  • user-education-...

  • user-emergency-contacts-...

  • user-family-...

  • user-holds-...

  • user-sources-...

Pre-scoped Mappings

Unlike star mappings which are entirely unscoped, some mappings are "pre-scoped".

Note: Pre-scoped Mappings are still available in the Import module, but they are considered deprecated. Using Star Mappings in all situations is recommended.

For example, user-addresses-city-* offers the ability to select an address "type" scope of "home" or "mailing".

user-adressess-home-city is "pre-scoped" to the "home" address type.

Similar example exist for evaluation types, school types (user-education-...) and family members positions.

Star Mapping Examples

Here are some common examples where star mappings are used.

Importing Historic Applications, One Row per Contact

In this example, we'll see one way star fields can be used to import multiple applications per row of the data file. This example is also discussed in our Importing Application Data article, here (option 2).

Example Data File

Let's imagine a data file where each row represents one contact. In the first column, we might have their ID, in the second their email and so on. In columns 33-38, we'll have data for their first application. In columns 39-44, data for a second application. We want to import the data from both applications.

Mapping

For columns 33-38, we'll map each column to it corresponding field in Element using the star fields. 33 is term, so it maps to user-applications-term-*. 34 is major, so user-applications-major-* and so on. This set of columns corresponds to the students first application, so we'll simply scope it to position 1. For columns 39-44, we'll use the same mappings but scope to position 2.

Expected Results

After running the import task, contacts should be created in Element451. Contacts should have the same number of applications as they had data for. If one contact only had data in columns 33-38, they should have one application listed on their Applications profile card. If another contact had data in columns 33-38 and 39-44, they should have two applications listed on their card.

Explanation

Importing historic applications usually occurs when first implementing Element451, so we can assume that these data files will create new contacts in Element. Since these contacts are new, we don't need to worry about overwriting existing data. Simply mapping to position will suffice. We can repeat this process for as many sets of columns as needed.

Pro Tip: This same strategy applies to all of the other repeaters listed. In fact, creating a data file with one row per contact is the preferred format for Imports.

Scoping to an Application by Term and Type

Type and Term are the most common scopes for Application mappings. Using them is the recommended method of matching a single application across multiple import tasks.

Example Data File(s)

In this example, we have two data files. Both correspond to a Undergraduate application type for Fall 2024.

In the first, each row represents one contact and contains data about an application they have started. In the first column, we might have their ID, in the second their email and so on. In column 20 we have the term for which they have started an application and in column 21 we have their major.

The second file also has one contact per row, but it contains additional information about the application that the student provided upon submission. We still their student ID in column 1 to identify them, but now in column 35 we have their student type and in 36 the campus where they want to study.

The goal is to write the data from file 2 to the same application created by file 1.

Mapping

In file 1, we'll map column 20 to user-applications-term-*, and column 21 to user-applications-major-*. For both, we'll scope the Application Type to "Undergraduate Application", as it's named in Element451. We'll also scope Term to "Fall 2024".

In file 2, we'll map column 35 to user-applications-student-type-* and column 36 to user-application-campus-*. Just like file 1, we'll scope Type to "Undergraduate Application" and Term to "Fall 2024".

Expected Results

After the first import task is run, we would expect contacts from the file to have one application on their Application profile card for Undergraduate Application, with a term of Fall 2024. The Major of that application should also be populated, but other fields blank.

After the second import task is run, we would expect contacts from the file to still have one application on their profile card for Undergraduate Application and Fall 2024, but now with more data, such as student type and campus.

Explanation

This process works because we know the application type and term is consistent for all contacts in both files. We can assume that existing contact's application data won't be overwritten because they have not had an application of this type from this term before. While other applications may exist on their record, none of them match that type and term combination.

In a given data file, if the type and term are varied, you will likely need to split that data file by type and term, creating a unique file for each type and term combination.

Exporting Student's School & Evaluation Data

It is common to export a student's highschool, college and test data when sending data from Element451 to another system. Repeating on Schools and Evaluations is effective, but produce two files. This example assumes a single export file is required.

Example Data File

In this example, we'll create a single file that repeats on the User (one row per student). We'll assume the contact and demographic data has already been mapped, and we now need to map the student's first and second highschool, first and second college, and ACT score.

Mapping

Beginning at the next available column of the export task, we'll map the following.

  1. user-education-schools-ceeb-*

  2. user-education-schools-gpa-*

  3. user-education-schools-ceeb-*

  4. user-education-schools-gpa-*

  5. user-education-schools-ceeb-*

  6. user-education-schools-gpa-*

  7. user-education-schools-ceeb-*

  8. user-education-schools-gpa-*

  9. user-evaluations-composite-score-*

Notice that user-education-schools-ceeb-* and user-education-schools-gpa-* are repeated four times. This corresponds to the four schools we wish to export.

We'll set the scope of the first set of ceeb-* and gpa-* mappings as:

School Type = Highschool

Position = 1

Then repeat this process for the remaining sets of schools, modifying the School Type and Position scopes as necessary.

The user-evaluations-composite-score-* mapping should be scoped to:

Type = ACT

Expected Results

After running the Export Task, the resulting file should have one row per student and should output student's schools and ACT score as configured. A student with only one highshool on record should have null values for the highschool 2 and college columns.

Did this answer your question?