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:

In SIS?	In LMS?	UDP Result
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.

Canvas Value (workflow_state)	UCDM Value (role_status)
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:

Field	Datatype	Description
COURSE_ROLE	TEXT	Canonical person role within the course
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.

Data Set	Field	Data Type	Description
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:

UCDM Value (role_status)	UCDM Value (enrollment_status)
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.