Element451Integrations Guide

Technical Overview

Updated Article

Introduction#

For a functional overview of how the integration works, see Functional Overview.

The Element451 integration with Anthology is designed to be simple from a user perspective, while handling complex data processing behind the scenes.

Element451 has built a baseline integration that interacts with standard endpoints and processes available through the Anthology API to sync basic student data, previous school history, applications, and documents to the SIS system, but there may be additional properties or fields your system is configured to use based upon your SOW.

Scope of This Guide#

This section provides a high-level technical overview of what occurs after the integration process is triggered by the webhook (see Functional Overview).

  • The process described here reflects the standard integration flow used for most partners
  • Some implementations may include customizations or exceptions based on specific requirements

For detailed information on Anthology endpoints, payloads, and data structures, refer to Anthology’s API documentation: https://developer.anthology.com/portal/displayApi/Student

Primary Tool#

Element451 uses Dagster to orchestrate all integration processes.

Dagster manages the following sync types:

  • Element451 → Anthology
  • Anthology → Element451

How It Works#

  • Dagster runs a series of jobs and sensors to monitor and execute integration activity.
  • Within each sync process, multiple operations (ops) are performed to:
    • Extract data
    • Transform data
    • Send or receive data between systems

Each sync is composed of these coordinated steps to ensure data is processed and transmitted correctly across systems.

Element451 → Anthology#

Extraction#

When the integration process is triggered, the first step is to load partner-specific configuration settings.

This includes:

  • API credentials
  • Element451 taxonomies and IDs
  • Field overrides and other configuration settings

These values are retrieved from Element451’s database and AWS Secrets.

Once configuration is loaded, Element451 extracts the contact record using the /v2/users/export API endpoint with a predefined template. This ensures all required data is included for integration with Anthology.

Translation#

After extraction, the data is translated into Anthology compatible values.

  • Anthology requires integer values for most fields (rather than the text friendly versions you see)
  • Element451 uses translation tables to map internal IDs and codes to the appropriate Anthology values.

Person Matching#

Next, the integration works to determine if its updating an existing record in Anthology or creating a new one.

  • If the Identity “Campus Nexus ID” exists on the Element record, it double checks it still returns a valid record. If so, it knows notes it will updating that record and moves on to the next operation.

If there is no “Campus Nexus ID” identity on the Element record, it prepares a series of criteria to then search on.  This criteria includes:

  • Email Addresses (personal and school/campus)
  • SSN

If it finds one student returned, it grabs the ID (Campus Nexus ID) and Student Number (Anthology ID) of the record and saves them in the Identities card of the Element record and moves on to the next operation as it has the Anthology record it will be updating.

If it finds more than one matching student, it returns an error back out to the integration log for review.

If it does not find any matching records, it moves to create a new one.  It creates a payload of data and then calls the /saveNew Anthology API to create the record.  The payload data consists of the following:

  • Name
  • Email Addresses
  • Phone Numbers
  • Biographic/Demographic data
  • Address
  • School Status
  • Assigned Admission Rep
  • Lead Source
  • Any custom field data if necessary.

After the record is created, it stores the ID (Campus Nexus ID) and Student Number (Anthology ID) in the Identities card of the Element record.

Update Student#

Next, if the Person Matching operation matched on an existing Anthology record (it did not create a new record), it will being a process of putting together a new payload for Anthology of all field data that exists in Element that needs to go over.  This payload data can consist of the following:

  • Name
  • Email Addresses
  • Phone Numbers
  • Biographic/Demographic data
  • Address
  • School Status
  • Assigned Admission Rep
  • Lead Source
  • Any custom field data if necessary.

Once built, it calls the /save Anthology API to update the record.

Create / Update Applications#

The application create/update process first starts by retrieving all application associated with the student in Anthology.

  • The process attempts to match Anthology applications to Element applications:
    • It first compares Element’s Application External ID to the ID on an Anthology application.
    • If there is no match, it then tries to compare by major and term.
  • For any matching application, the process performs an update command using /api/commands/Admissions/Applicant/save.
  • For any non-matched applications (new apps), it performs a create command using /api/commands/Admissions/Applicant/saveNew

This process sends over all application data including any decision associated with the application.

Create / Update Previous Schools#

The previous schools create/update process first starts by retrieving all schools associated with the student in Anthology.

  • The process attempts to match schools the Anthology student attended with schools in Element the student indicated they attended:
    • It first compares Element’s School External ID to the ID on an Anthology school record.
    • If there is no match, it then tries to search for a match by school name and school type (college vs. high school).
  • For any matching school records, the process performs an update command using /api/commands/Admissions/StudentPreviousEducation/save.
  • For any non-matched school records (new school history), it performs a create command using /api/commands/Admissions/StudentPreviousEducation/saveNew

This process sends over all school history.

Anthology → Element451#

Explanation#

Most of our partners choose not to sync Anthology data back to Element, but it is possible.  The process happens in two stages:

  • Anthology → Staging Area in Database
  • Staging Area in Database → Element

The first stage happens on a schedule of every 5 minutes, while the second stage is auto triggered by completion of the first stage on a record.

Anthology → Staging Area#

In this process we do a pull of data from several endpoints, combine the data together, and save the combined raw data out in a staging area.  It looks for students that have been updated any time in the last 5 minutes and runs this process on them (optionally filtering to only run on students with specific School Statuses).

Data Retrieval#

  • Student:
    • /api/commands/Common/Student/get
  • Applications:
    • /ds/campusnexus/Applicants
  • Previous Schools
    • /ds/campusnexus/StudentPreviousEducation

Staging Area → Element#

This process is triggered when a complete staging record is available.

It consists of three phases: Extract, Transform, and Import.

Extract#

  • Retrieve the combined Anthology record from staging

Transform#

Data is translated into Element451’s format values.  This consists of converting Anthology integer values for lookups (like Gender and Citizenship) and translating them into the correct Element data source values.

Additionally, the entire raw Anthology record is formatted for Element’s import payload design.

Import#

The transformed data from Anthology is then imported using Element’s API (/v2/users/import route).

Aside from the data, a source “CampusNexus Latest Sync” is added to Element’s Source codes collection with the current date/time indicating the record was sync’d in.