# Course Section Enrollment Role Status Mappings

#### Page Change Log <a href="#coursesectionenrollmentrolestatusmappings-pagechangelog" id="coursesectionenrollmentrolestatusmappings-pagechangelog"></a>

**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](https://forms.gle/V8dYut37B9yFoBdRA).

## Overview <a href="#coursesectionenrollmentrolestatusmappings-overview" id="coursesectionenrollmentrolestatusmappings-overview"></a>

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 <a href="#coursesectionenrollmentrolestatusmappings-udpcurrentrole_statusimplementation" id="coursesectionenrollmentrolestatusmappings-udpcurrentrole_statusimplementation"></a>

### SIS value vs. LMS value - which is the starting point? <a href="#coursesectionenrollmentrolestatusmappings-sisvaluevs.lmsvalue-whichisthestartingpoint" id="coursesectionenrollmentrolestatusmappings-sisvaluevs.lmsvalue-whichisthestartingpoint"></a>

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:

<table><thead><tr><th width="169.33333333333331">In SIS?</th><th width="175">In LMS?</th><th>UDP Result</th></tr></thead><tbody><tr><td><mark style="background-color:green;">Yes</mark></td><td><mark style="background-color:green;">Yes</mark></td><td><strong>SIS Value (UCDM enforced)</strong></td></tr><tr><td><mark style="background-color:green;">Yes</mark></td><td><mark style="background-color:red;">No</mark></td><td><strong>SIS Value (UCDM enforced)</strong></td></tr><tr><td><mark style="background-color:red;">No</mark></td><td><mark style="background-color:green;">Yes</mark></td><td><strong>LMS Value (UCDM enforced)</strong></td></tr></tbody></table>

### Current UCDM Mapping of *role\_status* <a href="#coursesectionenrollmentrolestatusmappings-currentucdmmappingofrole_status" id="coursesectionenrollmentrolestatusmappings-currentucdmmappingofrole_status"></a>

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](https://docs.udp.unizin.org/tables/ref_role_status.html).

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.](https://portal.inshosteddata.com/docs) 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 <a href="#coursesectionenrollmentrolestatusmappings-improvingthismapping-canvasdatatoucdm" id="coursesectionenrollmentrolestatusmappings-improvingthismapping-canvasdatatoucdm"></a>

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](https://portal.inshosteddata.com/docs#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 <a href="#coursesectionenrollmentrolestatusmappings-inactiveandcompleted-areasofdiscussion" id="coursesectionenrollmentrolestatusmappings-inactiveandcompleted-areasofdiscussion"></a>

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 <a href="#coursesectionenrollmentrolestatusmappings-inactivestatus" id="coursesectionenrollmentrolestatusmappings-inactivestatus"></a>

[Canvas’ definition of *inactive* enrollment](https://s3.amazonaws.com/tr-learncanvas/docs/CanvasEnrollmentStatusComparison.pdf) 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 <a href="#coursesectionenrollmentrolestatusmappings-completedstatus" id="coursesectionenrollmentrolestatusmappings-completedstatus"></a>

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 <a href="#coursesectionenrollmentrolestatusmappings-considerationsforotherlmssystems-d2landblackboard" id="coursesectionenrollmentrolestatusmappings-considerationsforotherlmssystems-d2landblackboard"></a>

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 <a href="#coursesectionenrollmentrolestatusmappings-blackboarddata-cdm_lms.person_course" id="coursesectionenrollmentrolestatusmappings-blackboarddata-cdm_lms.person_course"></a>

According to Blackboard Data documentation, the role and role status of enrollment is captured in the [CDM\_LMS.PERSON\_COURSE](https://data.blackboard.com/dictionary/entries/entry/CDM_LMS-PERSON_COURSE-COURSE_ROLE) table, of which four fields seems key here:

| Field                                                                                                        | Datatype  | Description                                     |
| ------------------------------------------------------------------------------------------------------------ | --------- | ----------------------------------------------- |
| [COURSE\_ROLE](https://help.blackboard.com/Learn/Administrator/Hosting/User_Management/Roles_and_Privileges) | 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 <a href="#coursesectionenrollmentrolestatusmappings-d2l-brightspace-data" id="coursesectionenrollmentrolestatusmappings-d2l-brightspace-data"></a>

According to the Brightspace documentation, the status of an enrollment is captured in the [Enrollments and Withdrawals](https://documentation.brightspace.com/EN/insights/data_hub/admin/bds_users.htm?tocpath=Administrators%7CBrightspace%20Core%20Analytics%7CAbout%20Brightspace%20Data%20Sets%7C_____34#Brightspace_Data_Set:_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](https://documentation.brightspace.com/EN/insights/data_hub/admin/bds_users.htm?tocpath=Administrators%7CBrightspace%20Core%20Analytics%7CAbout%20Brightspace%20Data%20Sets%7C_____34#Brightspace_Data_Set:_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](https://documentation.brightspace.com/EN/insights/data_hub/admin/bds_org_units.htm?Highlight=organizational%20units#Brightspace_Data_Set:_Org_Units) data set has the field *EndDate*, which identifies the end date of a course, and may be useful for defining enrollment status.

<table><thead><tr><th width="250">Data Set</th><th width="103">Field</th><th width="113">Data Type</th><th>Description</th></tr></thead><tbody><tr><td>Enrollments and Withdrawals</td><td>Action</td><td>varchar</td><td>Indicates whether the item is an enrollment or a withdrawal.</td></tr><tr><td>Users</td><td>IsActive</td><td>bit</td><td>Is user active?</td></tr><tr><td>Organizational Units</td><td>EndDate</td><td>datetime2</td><td>Availability end date (UTC).</td></tr></tbody></table>

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 <a href="#coursesectionenrollmentrolestatusmappings-unizinschangeproposal" id="coursesectionenrollmentrolestatusmappings-unizinschangeproposal"></a>

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 <a href="#coursesectionenrollmentrolestatusmappings-consortiumfeedbackandnextsteps" id="coursesectionenrollmentrolestatusmappings-consortiumfeedbackandnextsteps"></a>

Please submit your feedback on the proposed changes via [this Google Form survey](https://forms.gle/V8dYut37B9yFoBdRA) (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.