Element451Integrations Guide

Technical Overview

Updated Article

Introduction#

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

The Element451 integration with Workday sends application data from Element451 to Workday and then performs a follow-up lookup to retrieve key Workday-generated identifiers.

At a high level, the integration:

  1. exports the student/application record from Element451
  2. transforms the record into the Workday format
  3. checks whether the student already exists in Workday
  4. validates that the application can be sent
  5. creates the application in Workday using the Workday Admissions SOAP service
  6. saves Workday-generated identifiers back into Element451
  7. performs a delayed follow-up lookup to retrieve the Workday Student Reference ID and institutional email when available

Scope of This Guide#

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

The process described here reflects the standard shared Workday integration flow. Some partners may have additional project-specific customization, but the standard process is built around Element451 → Workday application creation and delayed retrieval of Workday-generated values.

Primary Tool#

Element451 uses Dagster to orchestrate Workday integration processes.

Dagster manages the sequence of operations used to:

  • read Workday configuration
  • export the student record from Element451
  • transform the student/application data
  • validate required fields
  • find or reference the Workday student
  • create the Workday application
  • save returned Workday identifiers
  • trigger delayed follow-up processing when needed

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 → Workday#

Explanation#

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

This includes:

  • API credentials (Test or Production)
  • 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 Ethos.  The data pulled out from Element is then converted into the a Workday data structure for use when sending the object to Workday’s API.

Student Matching#

Before creating the application in Workday, the integration checks whether the student already exists in Workday.

The matching process first looks for an existing Workday identifier saved in Element. If a Workday Student Reference ID or WID is already present, the integration treats the student as already created in Workday.

If no identifier is stored in Element, the integration attempts to find the student in Workday. It searches by first and last name, filters the results by matching name, then compares date of birth. If more than one Workday student matches the name and date of birth, the integration logs an error and exits for that record.

Required Field Validation#

After matching, the integration validates that the Element record has the data needed to continue.

The standard checks confirm:

  • the Element record has at least one application
  • load status is present
  • only one application exists when the partner configuration requires that
  • each application being sent has a submitted status
  • degree is present
  • term is present
  • student type is present

When a validation issue occurs, the integration logs the error and skips the affected record or application.

Translation#

After validation, the integration translates Element values into Workday-compatible values.

The shared process translates the student record and then translates each application before it is sent to Workday. Application translation includes values such as:

  • major
  • term
  • campus

These translated values are used to populate Workday reference fields in the application payload.

Application Creation#

Once the record is exported, matched, validated, and translated, the integration builds the Workday application payload and calls the Workday Admissions SOAP service.

The integration calls put_student_applications with Add_Only=True, which creates the application in Workday rather than updating an existing application. After Workday responds to the creation request, the integration retrieves the student WID, Student Reference ID, and Student Application ID from the response.

The application payload includes Workday references for values such as:

  • program of study
  • academic period
  • application source
  • applicant type
  • anticipated load status
  • campus/location
  • student tag (when configured)
  • secondary education
  • post-secondary education

Saving Workday Identifiers#

After Workday creates the application, the integration saves the Workday application identifier back to Element451.

If Workday returns a newly created student WID or Student Reference ID, the integration also saves the student identifier back to Element451. If Workday creates the student but does not immediately return a Student Reference ID, the integration saves the student WID and queues delayed follow-up processing.

Delayed Workday Data → Element451#

Explanation#

After the Workday application is created, some Workday-generated values may not be available immediately.

To account for that delay, the integration creates a delayed event when a new Workday student WID is returned. The delayed event is scheduled for a later retry time, giving Workday time to generate the remaining student data.

Delayed Lookup#

The delayed lookup process reads the Workday student WID and calls Workday to retrieve the student application data.

It then attempts to extract:

  • Workday Student Reference ID
  • institutional email address

If both values are found, the delayed event is removed from the queue and the values are output for saving back into Element.

Warnings#

If the final delayed attempt occurs and Workday still has not generated the Student Reference ID or institutional email, the integration logs warnings and then marks the log record as successful if no errors are present.

Error Handling and Integration Logs#

The Workday integration writes sync results and errors to the integration log.

Errors may occur during:

  • Element export
  • missing required fields
  • multiple Workday student matches
  • unsupported or missing application values
  • Workday application creation
  • delayed retrieval of Workday-generated values

When errors occur, the integration logs the details against the Element record so they can be reviewed and resolved before retrying.