Course Section Enrollment Role Status Mappings
Page Change Log
Wednesday, March 9, 2022 - Extending Feedback Deadline
Given March has spring break for all of our schools, we are extending the feedback deadline from March 22nd to April 1. Another round of comms will go out closer to the new deadline to encourage as much feedback as possible. Again, the Google Form link is here.
Overview
Accurate student enrollment reporting is essential to both operational and learning science applications. The UDP captures enrollments in courses via the course_section_enrollment entity. This entity is the result of a combination of the representation of enrollments captured both in the SIS and LMS systems. Unizin has discovered recently an opportunity to improve how the UDP maps enrollment statuses (named role_status in the course_section_enrollment entity).
The purpose of this document and corresponding Google Form survey is the following:
Clearly define how the UDP currently implements the enrollment role status (role_status field) mappings
Identify the areas we can clarify or improve this mapping
Gather consensus via the survey on the changes the consortium would like Unizin to make to the mappings.
UDP Current role_status Implementation
SIS value vs. LMS value - which is the starting point?
Like many entities and elements in the UCDM, the construction of the role_status takes both SIS and LMS information into account for every row. For a given row representing a person-to-course enrollment, if both the SIS and LMS have a value for role_status, the UCDM will favor the value coming from the SIS as the source of truth. The LMS value is taken in the absence of a row in the SIS system. This gives the following possibilities:
Yes
Yes
SIS Value (UCDM enforced)
Yes
No
SIS Value (UCDM enforced)
No
Yes
LMS Value (UCDM enforced)
Current UCDM Mapping of role_status
After the UDP determines which source system’s value to favor, the Unizin Common Data Model (UCDM) enforces a consistent mapping of the value, which is the value ultimately shown in the role_status field in course_section_enrollment. The current possible values for the role_status UCDM value are shown in this option set.
The UDP only accepts SIS data that already has the UCDM enforced. Meaning, SIS teams usually take the raw SIS data and enforce the above option set mapping before sending the data to the UDP. In other words, SIS data teams have the ability to adjust the logic for these mappings as needed; once the UDP sees valid SIS data, no transformations happen on that data.
On the other hand, LMS data comes to the UDP directly from Canvas without the UCDM enforced. The UDP initially sees the LMS data in the exact schema as defined by the Canvas Data API. Unizin then takes the raw Canvas data and enforces the UCDM uniformly to all UDP instances. This uniform mapping is owned by Unizin and is the focus for how the role_status mappings can be improved across the Unizin Consortium.
Improving this Mapping - Canvas Data to UCDM
The following table outlines how the UCDM enforces the role_status option set based on the values seen in the raw Canvas Data. For reference, the Canvas Data entity that contains the source value is enrollment_dim via workflow_state.
active
Enrolled
inactive
Enrolled
completed
Enrolled
rejected
Not-enrolled
deleted
Withdrawn
invited
Pre-registered
creation_pending
Registered
Inactive and Completed - Areas of Discussion
Unizin is currently focused on improving the mappings with the inactive and completed Canvas Data values. We discovered that grouping of active, inactive, and completed into a single, UCDM status of enrolled can cause confusion, especially when comparing enrollment reports previously built on Canvas Data versus those built on the UDP. As an example using fabricated numbers:
Canvas workflow_state
# Records
UCDM role_status
# Records
active
10000
Enrolled
11500
inactive
1000
completed
500
For both the Canvas and UCDM sides, 11.5K records are reported and correctly in scope. However, the UCDM side shows only one type of record while the Canvas side shows three. Comparing numbers one-for-one between the Canvas and the UCDM can be tricky. The numbers might look “off” if one assumes that only active Canvas records are Enrolled in the UDP.
Inactive Status
Canvas’ definition of inactive enrollment is a bit tricky. Inactive students are unable to access any part of their inactive courses and are unable to submit assignments. In this way, inactive students behave similarly to Withdrawn students.
However, inactive students still show up on instructor rosters and course analytics. Also, instructors and admins do have the ability to identify and reactivate inactive students, making those students active again. Based on this information, inactive feels closer to Enrolled, and if reporting requires a full list that matches a Canvas roster, then mapping inactive to Enrolled enables this ability. A distinction here, too, between Withdrawn students is that inactive students do not normally pursue this workflow_state voluntarily, as would be the case when a student “drops” a course. A student does not initiate an inactive status.
Striking the balance between these two interpretations is a main source of confusion. Inactive feels similar to both Withdrawn and Enrolled but also feels distinct to both of those statuses as well. Furthermore, the ability to include or exclude inactive students likely has value given its somewhat confusing, unique nature.
Completed Status
Completed students are those that have finished a course and can only access course content in a read-only format. It is most likely that these students previously maintained an active status prior to completing the course, so mapping this value to Enrolled can make sense. However, there may be value in distinguishing based on time and accessibility (e.g. ability to submit for new assignments, post in discussions, etc.).
Considerations for other LMS Systems - D2L and Blackboard
Beyond just Canvas, though, Unizin must ensure that the option sets for role_status can fit with the data properties of other LMS systems in scope for future UCDM development: Blackboard and D2L.
Blackboard Data - CDM_LMS.PERSON_COURSE
According to Blackboard Data documentation, the role and role status of enrollment is captured in the CDM_LMS.PERSON_COURSE table, of which four fields seems key here:
AVAILABLE_IND
BOOLEAN
Shows if a user can access the course
ROW_INSERTED_TIME
TIMESTAMP
Date and time the record was added to the table
ROW_DELETED_TIME
TIMESTAMP
Date and time the record was marked as removed
For this discussion of role_status values of Enrolled, Inactive, Completed, and Withdrawn we think Blackboard data fits with the following criteria:
Enrolled - a row has AVAILABLE_IND set, ROW_INSERTED_TIME is not null, and ROW_DELETED_TIME is null. Note: further logic is probably needed to join with academic term data to determine if the course is currently in instruction. If the course is active in the current term, this criteria marks an Enrolled role_status.
Inactive - a row has AVAILABLE_IND not set, ROW_INSERTED_TIME is not null, and ROW_DELETED_TIME is null. This captures the same behavior as in Canvas for Inactive. A student can still show up in the roster (ROW_DELETED_TIME is null), but the student is unable to access any course content (AVAILABLE_IND is not set).
Completed - a row has AVAILABLE_IND set, ROW_INSERTED_TIME is not null, and ROW_DELETED_TIME is null. Note: further logic is probably needed to join with academic term data to determine if the course is currently in instruction. If the course is not actively in instruction for the current term, this criteria marks a Completed role_status.
Withdrawn - a row has ROW_DELETED_TIME not null.
D2L (Brightspace) Data
According to the Brightspace documentation, the status of an enrollment is captured in the Enrollments and Withdrawals data set, which contains all the enrollments and withdrawals for users in an organization. The relevant field is Action, which denotes whether a student enrolled or withdrew from a course. Another data set that may help us identify enrollment status is the Users data set. An important field for this data set is IsActive, which denotes whether a user is active or inactive. Finally, the Organizational Units data set has the field EndDate, which identifies the end date of a course, and may be useful for defining enrollment status.
Enrollments and Withdrawals
Action
varchar
Indicates whether the item is an enrollment or a withdrawal.
Users
IsActive
bit
Is user active?
Organizational Units
EndDate
datetime2
Availability end date (UTC).
D2L data seems to fit the role_status values of Enrolled, Inactive, Completed, and Withdrawn with the following criteria:
Enrolled - A row in Enrollments and Withdrawals where Action = ‘Enrolled.’
Withdrawn - A row in Enrollments and Withdrawals where Action = ’Withdrawn.’
Inactive - There does not seem to be a status for Inactive enrollments in Enrollments and Withdrawals. Active/inactive statuses seem to be only done at the user level, and not also at the enrollment level. For example, the Users data set includes an IsActive field, which states whether a user is active or inactive. If a student is inactive, they do not have access to the Brightspace Learning Environment, but their enrollments are not deleted, and they can be reactivated. In other words, the inactive status is only at the user level, and affects all of a user’s enrollments. This is different from Canvas where a user can be inactive at the enrollment level also, meaning that a user can be denied access to one course but still be active in other courses.
Completed - Again, there is not a status for Completed enrollments in Enrollments and Withdrawals. To determine if an enrollment is completed, however, we should be able to use the Enrollments and Withdrawals table with the Organizational Units table. If a student is enrolled in a course that has ended, we could define their enrollment status as being Completed. To do this, we should be able to use the OrgUnitID foreign key in Enrollments and Withdrawals to join with Organizational Units. If a row in the Enrollments and Withdrawals table has Action = ‘Enrolled’ and the corresponding row in the Organizational Units table has an EndDate earlier than the current date, then the enrollment status would be Completed.
Unizin’s Change Proposal
Given all of the considerations above, Unizin proposes to add a new field in the course_section_enrollment entity named enrollment_status. This will be a string-valued, option set field. The current mapping values and logic in role and role_status will remain unchanged. Instead, the new enrollment_status field will help differentiate between users that may still appear on rosters and faculty-facing analytics based on how those users can currently interact with the LMS. A full UCDM proposed mapping table for role_status and enrollment_status is below:
Enrolled
Active
Inactive
Completed
Not-enrolled
Not-enrolled
Withdrawn
Not-enrolled
Pre-registered
Not-enrolled
Registered
Not-enrolled
Canvas data specifically will be mapped into these fields in the following ways:
Canvas Value (workflow_state)
UCDM Value (role_status)
UCDM Value (enrollment_status)
active
Enrolled
Active
inactive
Enrolled
Inactive
completed
Enrolled
Completed
rejected
Not-enrolled
Not-enrolled
deleted
Withdrawn
Not-enrolled
invited
Pre-registered
Not-enrolled
creation_pending
Registered
Not-enrolled
The new enrollment_status field has the most value differentiating between the Enrolled role_status values. The other UCDM role_status fields other than Enrolled all map to Not-enrolled since students with these role_status values are absent in courses (both from what the student can see and what the instructor can see).
Consortium Feedback and Next Steps
Please submit your feedback on the proposed changes via this Google Form survey (which should take less than 5 minutes to complete). The survey is not anonymous, as we would like to follow up with people specifically for more ideas/feedback as needed. Unizin will judge the amount of consortium consensus based on the results of the survey, and if the consortium largely agrees on the path forward, Unizin will begin scoping technical work to implement this change to the UDP. Deadline to complete the survey is March 22, 2022.
Last updated
