| Overview | Importing This File |
| Video Explaining This File | What Data Can Be Updated |
| Populating This File | Products That Use This File |
| Next: Instructors | |
Overview
This file enrolls students in sections for a given term, building class rosters within the applicable Anthology products that are used to aggregate data connected to user accounts, provide instructor permission to student data, and facilitate analysis at the student level.
The Credits, StartDate, and EndDate optional fields can be used to override the same fields from the Sections file. If these fields are not populated on a record, the system will default to the value on the course record to which the section is linked. Consider whether individual student enrollments ever have different credits or dates from the overall sections when deciding whether to populate these fields. If you are a campus using Insight, you should include all optional fields regardless of whether they are the same as the course.
Video Explaining the Enrollments File
Best Practices for Populating Enrollments
Scope
Determine whether there are any enrollments that should be excluded from your imports to Core Data based on local practices or usage goals. These decisions should align with the scope decisions made in building the Course and Section files but may also include decisions about individual enrollments such as audits, dual enrolled students, or transfer placeholders.
Data relationships
The Enrollments file references two identifiers that are defined in other files: SectionIdentifier and PersonIdentifier. These identifiers must either be present on the enrollment tables or be able to be mapped through another table or view to match the identifiers used in the Sections and Accounts files.
Status
The status field is used to enroll and unenroll students in each section; enrollments cannot be removed once they are imported. The importer accepts a set of enumerated values that should be scripted using case statements based on the decisions discussed below. Enrollment records with a status of Dropped or Withdrawn will be removed from the class roster.
- Enrolled: the student is enrolled in the section, which has not yet begun. The script should compare the current date to the start date of the section.
- Active: the student is enrolled in the section, which is currently ongoing. The script should compare the current date to the start and end dates of the section.
- Completed: Discuss how your institution defines a “completed” enrollment. Typically this will be a student who is enrolled in the section that has completed, but you also need to decide whether students with incomplete grades will be marked “active” or “completed.” The script should compare the current date to the end date of the section.
- Dropped/Withdrawn: Discuss institutional policies around drops and withdraws and determine how they are reflected in the data. Use case statements to map SIS data to the enumerated values.
StatusChangeDate
This field should only be populated on records with a Status of “Dropped” or “Withdrawn”. This date helps users determine if a drop occurred before or after the add/drop date when building analyses.
RegistrationDate
Populate this field with the date the student is enrolled into the section; This should not include waitlisted students.
GradeOption
The enrollments import only accepts 3 enumerated values for GradeOption: “Graded,” “CrNc” (pass/fail), and “Audit.” These values need to be mapped from the codes used in the SIS using case statements in the SQL scripts. The exact mapping depends on your institution’s usage of these codes in the SIS and how grading and enrollments work on your campus. Review any fields related to grade type in your data and use them to guide your decision-making process.
Term Logic
For the fullest analytical view of enrollment changes and melt, scripts should be written to begin extracting enrollments as soon as registration for that term opens. As students drop or withdraw from sections, their status will be updated to remove them from the class roster.
When building this script, consider whether your institution deletes pre-term drops from the SIS. If the enrollment record is deleted instead of simply marked dropped, you may not be able to update their status to dropped in your Enrollment data set. In this situation, you may want to consider not extracting data for a given term until after these drops are addressed.
Enrollment data for a given term should continue to be pulled until no more changes will be made. Discuss your institutional incomplete policy to determine how long after the end of a term the grade can be updated, and script the term logic accordingly.
Suggested SIS Tables
Important Information About Importing This File
Import Order
The Enrollments file must be imported after the sections file.
What Data Can Be Updated
In order to unenroll a student from a course section they must be imported in this file with a status of dropped or withdrawn.
Products That Use the Enrollments File
| Product | Required | Optional | Not Applicable |
| Baseline - Rubrics | |||
| Beacon | |||
| Engage | |||
| Evaluate | |||
| Insight | |||
| Outcomes | |||
| Planning |
Requirements for populating this file can be found in the Core Data Dictionary.
Comments