🚀 Case Management is in Open Beta

Case Management is now in Open Beta and available to all customers on the Student Success package. It's actively evolving, so some capabilities are still on the way. To provide feedback and share with others, visit our User Community Group.

Overview

Alerts and Cases can be imported and exported in bulk using Element451's Import + Export module. Use imports to migrate historical alert and case data from a legacy early-alert system or load records from an external system of record, and use exports to send alert and case data to data warehouses, reporting tools, or other campus systems.

Alert and case fields work inside the same import and export tasks you already use for contact data. There is no separate task type: you map alert and case fields alongside contact fields in a single task.

How Import + Export Works for Case Management

Each row in an import file can create or update an alert, a case, or both, attached to a contact. Element451 first matches the row to a contact using your import's Matching Settings (Element ID, email address, or external ID), then creates or updates the alert and case on that contact's record.

External IDs and Re-Imports

Map an External ID whenever your data comes from another system. The external ID acts as the unique key for each alert or case, so re-importing the same file (or running a scheduled import) updates the existing record instead of creating a copy. Rows with no changes are reported as unchanged.

🚨 Important: Without an external ID, every import run creates new alerts and cases. If you plan to import from the same source more than once, include an external ID column from the start.

Multiple Alerts or Cases for One Contact

A row can carry one alert and one case together. A contact with several alerts needs one row per alert, repeating the contact's matching column on every row. This mirrors how exports work, where Repeat Fields Based On emits one row per alert or case, so a file you export has the same row shape as an import file, though a few column names differ. See Exporting Alerts and Cases below.

If several rows belong to the same case, map the same Case External ID on each row. The case is created once and reported as unchanged on the remaining rows, rather than duplicated.

Email	Alert External ID	Case External ID
jordan.reyes@example.edu	ALERT-1001	CASE-4471
jordan.reyes@example.edu	ALERT-1002	CASE-4471
jordan.reyes@example.edu	ALERT-1003	CASE-4471

That file produces three alerts and one case.

Case Statuses and Status Categories

Every Case status you create in Case Settings > Statuses belongs to one of four system status categories: To Do, In Progress, Resolved, or Cancelled. The category is the bucket; your status is the specific label inside it. A school might have three statuses in the Resolved category, for example Resolved - Re-engaged, Resolved - Withdrew, and Resolved - Referred Out.

Import gives you a column for each level. Which one you map depends on how precise your source data is:

Column	Use it when	What to put in the cell
Custom Status	You know exactly which status each record belongs on	The status name, for example Resolved - Re-engaged
System Status Category	Your source data only distinguishes open from closed	A category: `todo`, `in_progress`, `resolved`, `cancelled`

Neither one requires you to look anything up. If you map both, Custom Status wins.

🚨 Important: If you map System Status Category, Element451 files the record under the status flagged default in that category. If no default is set, it uses the first enabled status in the category. On an instance with three Resolved statuses and no default, that choice is arbitrary, so map Custom Status whenever you care which one.

📙 Note: Alert statuses are not customizable. There is exactly one alert status per category, so for alerts the two columns always reach the same status. Mapping System Status Category is the simpler choice.

Translating Values with System Mapping

Type, priority, and status values are translated between your file's values and Element451's using System Mapping column settings, on both import and export. This defaults to matching on name, so a school can map its historical data straight onto its own custom case statuses and priorities without looking up internal IDs.

System Mapping's Interpret as setting defaults to Name, so your file can carry the value's name as it appears in your settings.
Switch it to Guid if your file carries Element451 GUIDs instead, which also keeps a scheduled import working if someone later renames the value.
- To find a GUID, open the relevant settings list, Alert Types, Alert Priorities, Case Types, Case Statuses, or Case Priorities, and choose Copy GUID from a row's three-dot menu.

Importing Alerts and Cases

🚨 Important: Check your automations before running a large import. Imported alerts and cases are created like any other record, so they trigger the same automation rules and workflows a manually created alert or case would. A single historical import can escalate alerts, auto-create cases from templates, assign owners, spawn tasks, and send notifications, all at once and all at the moment you run it.

To import alerts or cases:

Create a new import task and choose your source (computer upload, SFTP, Dropbox, or Google Drive). See Creating Imports for the full walkthrough.
In the mapping step, map your file's columns to fields from the Alerts and Cases field groups, alongside any contact fields you need for matching.
Apply System Mapping column settings to type, priority, and status columns as needed.
Confirm your Matching Settings.
Review your active automations. See below.
Run a Test Import, review the results, then run the import.

Reviewing Active Automations

Two things in Element451 can fire when an alert or case is created, and both apply to imported records:

Alert and case automation rules, including actions that create a case from an alert or apply a Case Template.
Workflows that use alert or case creation as their trigger.

Whether that is helpful depends entirely on what you're importing:

What you're importing	Should automations run?
A live or scheduled feed of new alerts from an external system	Usually yes. You want incoming alerts routed, assigned, and escalated exactly as if staff had created them.
Historical or already-closed records from a legacy system	Usually no. Years of past alerts can generate a flood of new cases, tasks, assignments, and notifications about students whose issues were resolved long ago.

✨ Pro Tip: Import a handful of rows first and look at what happened afterward, not just at Run History. Check whether new cases, tasks, or assignments appeared that you didn't map in your file. That tells you which automations are in play before you run the full file.

Matching Settings

Because alerts and cases attach to a contact that already exists, your Matching Settings have to identify that contact. Two configurations cause every row to fail, and both are easy to hit:

Configuration	What happens
Update Preference is Update Existing but no match field is selected	Nothing can be matched, so every row is treated as a new contact and rejected with "Email has already been taken."
Update Preference is Import New and Update Existing but no match field is selected	Same result. The match field, not the update preference, is what finds the contact.

Always select a match field, normally Email, Element ID, or an external ID. If your file contains contacts that don't exist yet, use Import New and Update Existing so they are created rather than rejected.

✨ Pro Tip: If every row fails with "Email has already been taken," your match field is missing. The import is trying to create contacts that already exist instead of matching them.

Alert Import Fields

Field	Field ID	Description	Required
Type	`alerts-type`	The alert type. Must match an existing alert type in your instance; use System Mapping to translate external values.	Yes
Name	`alerts-name`	The alert's name.	Yes
Custom Status	`alerts-status`	A specific alert status, given by name. Alert statuses are not customizable and there is exactly one per category, so mapping System Status Category instead reaches the same status. Takes precedence over System Status Category when both are mapped.	No
System Status Category	`alerts-system-status`	The system state the alert sits in. One of `triage`, `in_progress`, `escalated_to_case`, `resolved`, or `dismissed`. The recommended way to set an alert's status on import. Map it when migrating historical alerts so closed records don't land back in Triage.	No
Priority	`alerts-priority`	The alert priority, given by name as it appears in your priority settings. When this column is not mapped, the instance default priority is used.	No
Assignee	`alerts-assignee`	The reviewer responsible for triaging the alert. Accepts comma-separated user or team ObjectIds; names and email addresses are not accepted. Find a user's ObjectId in Settings > Manage Users by opening the user and copying the ID from the URL. Do not put a space after the comma, and wrap a multi-value cell in double quotes: `"5f0a1b2c3d4e5f6071829304,6b1c2d3e4f5a6b7c8d9e0f11"`. A space skips the entire row, not just the assignee.	No
Description	`alerts-description`	The alert description.	No
Due Date	`alerts-due-date`	When the alert is due.	No
Notes	`alerts-notes`	A note added to the alert. Each import run appends a note rather than replacing the existing one, so re-importing the same file adds a duplicate note. Import only; notes are not available on export.	No
Course Enrollments	`alerts-course`	Links the alert to one or more course enrollments. Accepts comma-separated course enrollment GUIDs.	No
Associated Case	`alerts-case`	Relates the alert to an existing case. This column takes the case's GUID, for example `elementu.cases.891`, not a name. Setting it links the case and records that case's current status on the alert, but does not change the alert's own status. *see more details below	No
Created Date	`alerts-created-date`	The alert's original creation date. Defaults to the import run time; map this when migrating historical data. The export equivalent uses a different field ID, `alerts-created-at`.	No
External ID	`alerts-external-id`	The alert's unique ID in your external system. Enables updates on re-import.	No

📙 Note: An alert in the escalated_to_case category does not need a related case. You can import an alert as escalated without mapping Associated Case.

Associated Case (alerts-case)

When using the Associated Case field, it's important to know that it only takes the internal case GUID, which only exists after Element451 has created the case. You cannot relate an alert to a case created in the same import run.

Finding a case GUID:
- For a bulk migration, import your cases first, then export them and read the GUIDs out of the export.
- For one or two cases, open the case, use the copy link icon, and paste the link somewhere: it looks like https://yourschool.element451.io/v2/case-management?caseGuid=yourschool.cases.900, and the value after caseGuid= is the GUID. Then import your alerts with those GUIDs mapped. To reproduce an alert's escalated state fully, map both Associated Case and System Status Category (escalated_to_case).

Case Import Fields

Field	Field ID	Description	Required
Type	`cases-type`	The case type. Must match an existing case type in your instance; use System Mapping to translate external values.	Yes, when creating new cases
Name	`cases-name`	The case name.	No
Custom Status	`cases-status`	A specific status from your case status workflow, given by name, for example Resolved - Re-engaged. Use this when migrated cases need to land on a particular status. Takes precedence over System Status Category when both are mapped.	No
System Status Category	`cases-system-status`	The category a status belongs to: `todo`, `in_progress`, `resolved`, or `cancelled`. Map this instead of Custom Status when your source data only distinguishes open from closed. Element451 files the record under the status flagged default in that category, or the first enabled status if no default is set. Your instance must have at least one enabled status in the category or the row fails.	No
Priority	`cases-priority`	The case priority, given by name as it appears in your priority settings. When this column is not mapped, the instance default priority is used.	No
Assignee	`cases-assignee`	The case owner. Accepts comma-separated user or team ObjectIds; names and email addresses are not accepted. A row can assign users or a team, but not both. Find a user's ObjectId in Settings > Manage Users by opening the user and copying the ID from the URL. Do not put a space after the comma, and wrap a multi-value cell in double quotes: `"5f0a1b2c3d4e5f6071829304,6b1c2d3e4f5a6b7c8d9e0f11"`. A space skips the entire row, not just the assignee.	No
Description	`cases-description`	The case description.	No
Due Date	`cases-due-date`	When the case is due.	No
Private	`cases-private`	Marks the case as private. Accepts `true` or `false`. Private cases require at least one assignee.	No
Created Date	`cases-created-date`	The case's original creation date. Defaults to the import run time; map this when migrating historical data. The export equivalent uses a different field ID, `cases-created-at`.	No
External ID	`cases-external-id`	The case's unique ID in your external system. Enables updates on re-import, and lets multiple rows attach to the same case.	No

CSV Example Templates

Testing and Tracking Results

Use Test Import to run a dry run before committing: it validates every row and reports how many alerts and cases would succeed or fail, without writing anything.

Reading Run History

Run History looks different for alert and case imports than for any other import you run, and the reason is worth understanding.

Alerts and cases are the only data you can import that is not written directly to the contact profile. Everything else an import touches, bio-demographic fields, test scores, applications, lives on the contact record itself. Alerts and cases are separate records that reference a contact. Run History reflects that split.

Each run reports on three levels:

Row	What it counts
The first row, with the run's date and time	The contact records.
Alerts	The alert records created, updated, skipped, failed, or unchanged.
Cases	The case records created, updated, skipped, failed, or unchanged.

🚨 Important: Expect the contact row to report Unchanged for every row in your file. That is the expected behavior. You are attaching alerts and cases to contacts, not editing the contacts themselves, so no contact data changed. A run showing "0 added, 0 updated, 25 unchanged" on the contact row and "25 added" on the alerts row imported 25 alerts successfully.

Read the alert and case rows to judge whether the import worked. The contact row only tells you how many contacts were matched.

✨ Pro Tip: Always run a Test Import when setting up a new mapping. Row-level error reasons let you fix your file or mapping before any records are created.

Exporting Alerts and Cases

Repeat fields give you one row per alert or case, with the contact's fields repeated on each row. Set Repeat Fields Based On to Alerts or Cases, then map from the field tables below.

To export alerts or cases:

Create a new export task. See Creating Exports for the full walkthrough.
Set Repeat Fields Based On to Alerts or Cases. Each alert or case exports as its own row, repeating the contact fields you include.
Map the alert or case fields you need. Most import fields are available on export, plus the record GUID and created and updated timestamps. See the field tables below.
Use Items To Export, Order By, and Conditions to control which records are included.
Choose a destination (email, SFTP, Dropbox, or Google Drive) and run the export, or put it on a recurring schedule with Scheduling Import + Export.

Alert Export Fields

Field	Field ID	Notes
GUID	`alerts-guid`	The alert's Element451 GUID. Export only.
External ID	`alerts-external-id`	The alert's ID in your external system.
Name	`alerts-name`
Type	`alerts-type`
Custom Status	`alerts-status`
System Status Category	`alerts-system-status`
Priority	`alerts-priority`
Assignee	`alerts-assignee`	Exports as comma-separated user or team ObjectIds.
Description	`alerts-description`
Due Date	`alerts-due-date`
Course Enrollments	`alerts-course`	Exports as comma-separated course enrollment GUIDs.
Associated Case	`alerts-case`	The linked case's GUID. Useful for collecting case GUIDs to use on a later import.
Created At	`alerts-created-at`	Export only. Note the different field ID from the import column, `alerts-created-date`.
Updated At	`alerts-updated-at`	Export only.

Case Export Fields

Field	Field ID	Notes
GUID	`cases-guid`	The case's Element451 GUID. Export only. This is the value the Associated Case import column expects.
External ID	`cases-external-id`	The case's ID in your external system.
Name	`cases-name`
Type	`cases-type`
Custom Status	`cases-status`
System Status Category	`cases-system-status`
Priority	`cases-priority`
Assignee	`cases-assignee`	Exports as comma-separated user or team ObjectIds.
Description	`cases-description`
Due Date	`cases-due-date`
Private	`cases-private`
Created At	`cases-created-at`	Export only. Note the different field ID from the import column, `cases-created-date`.
Updated At	`cases-updated-at`	Export only.

Calculated Alert/Case Traits

Calculated traits for Case Management live on the contact record itself, so they come back on a normal contact export with one row per student and no repetition. Use these when you want counts rather than detail, for example a retention report that needs each student's open case count alongside their persistence data.

Field	Field ID
Total Alerts	`user-calculated-total_alerts`
Total Open Alerts	`user-calculated-total_open_alerts`
Total Closed Alerts	`user-calculated-total_closed_alerts`
Total Escalated Alerts	`user-calculated-total_escalated_alerts`
Total Cases	`user-calculated-total_cases`
Total Open Cases	`user-calculated-total_open_cases`
Total Resolved Cases	`user-calculated-total_resolved_cases`
Total Canceled Cases	`user-calculated-total_cancelled_cases`

🚨 Important: An export is not a ready-to-import file. Three differences to expect: created dates use different field IDs (alerts-created-at and cases-created-at on export, alerts-created-date and cases-created-date on import), so rename or remap that column; GUID and Updated At are export only and have no import counterpart; and Notes are import only, so notes do not round-trip.

✨ Pro Tip: Exporting alerts with Associated Case mapped, or exporting cases with GUID mapped, is the fastest way to collect case GUIDs in bulk. That is exactly what the Associated Case column needs on a later import.

Importing + Exporting Alerts and Cases [Beta]