Default Enterprise Enrollments

Default Enterprise Enrollments#

Status#

Proposed - October 2024

Context#

Enterprise needs a solution for managing automated enrollments into “default” courses or specific course runs for enterprise learners. Importantly, we need this solution to work for learners where we have no information about the identity of learner who will eventually be associated with an EnterpriseCustomer. For that reason, the solution described below does not involve PendingEnrollments or anything similar - that model/domain depends on knowing the email address of learners prior to their becoming associated with the customer. The solution also needs to support customer-specific enrollment configurations without tightly coupling these configurations to a specific subsidy type, i.e. we should be able in the future to manage default enrollments via both learner credit and subscription subsidy types.

Core requirements#

  1. Internal staff should be able to configure one or more default enrollments with either a course or a specific course run for automatic enrollment. In the case of specifying a course, the default enrollment flow should cause the “realization” of default enrollments for learners into the currently-advertised, enrollable run for a course.

  2. Default Enrollments should be loosely coupled to subsidy type.

  3. Unenrollment: If a learner chooses to unenroll from a default course, they should not be automatically re-enrolled.

  4. Graceful handling of license revocation: Upon license revocation, we currently downgrade the learner’s enrollment mode to audit. This fact should be visible from any new APIs exposed in the domain of default enrollments.

  5. Non-enrollable courses: If a course becomes unenrollable, our intent is that default enrollments for such a course no longer are processed. Ideally this happens in a way that is observable to operators of the system.

Decision#

We will implement two new models:

  • DefaultEnterpriseEnrollmentIntention to represent the course/runs that learners should be automatically enrolled into, post-logistration, for a given enterprise.

  • DefaultEnterpriseEnrollmentRealization which represents the mapping between the intention and actual, realized enrollment record(s) for the learner/customer.

Qualities#

  1. Flexibility: The DefaultEnterpriseEnrollmentIntention model will allow specification of either a course or course run.

  2. Business logic: The API for this domain (future ADR) will implement the business logic around choosing the appropriate course run, for answering which if any catalogs are applicable to the course, and the enrollability of the course (the last of which takes into account the state of existing enrollment records).

  3. Non-Tightly Coupled to subsidy type: Nothing in the domain of default enrollments will persist data related to a subsidy (although a license or transaction identifier will ultimately become associated with an EnterpriseCourseEnrollment record during realization).

Flexible content keys on the intention model#

The content_key on DefaultEnterpriseEnrollmentIntention is either a top-level course key or a course run key during configuration to remain flexible for internal operators; however, we will always discern the correct course run key to use for enrollment based on the provided content_key.

Post-enrollment related models (e.g., EnterpriseCourseEnrollment and DefaultEnterpriseEnrollmentRealization) will always primarily be associated with the course run associated with the DefaultEnterpriseEnrollmentIntention:

  • If content_key is a top-level course, the course run key used when enrolling (converting to EnterpriseCourseEnrollment and DefaultEnterpriseEnrollmentRealization) is the currently advertised course run.

  • If the content_key is a specific course run, we’ll always try to enroll in the explicitly configured course run key (not the advertised course run).

This content_key will be passed to the EnterpriseCatalogApiClient().get_customer_content_metadata_content_identifier method. When passing a course run key to this endpoint, it’ll actually return the top-level course metadata associated with the course run, not just the specified course run’s metadata (this is primarily due to catalogs containing courses, not course runs, and we generally say that if the top-level course is in a customer’s catalog, all of its course runs are, too).

If the content_key configured for a DefaultEnterpriseEnrollmentIntention is a top-level course, there is a chance the currently advertised course run used for future enrollment intentions might change over time from previous redeemed/enrolled DefaultEnterpriseEnrollmentIntentions. However, this is mitigated in that the DefaultEnterpriseEnrollmentRealization ensures the resulting, converted enrollment is still related to the original DefaultEnterpriseEnrollmentIntention, despite a potential content_key vs. enrollment course run key mismatch.

Consequences#

  1. It’s a flexible design.

  2. It relies on a network call(s) to enterprise-catalog to fetch content metadata and understand which if any customer catalog are applicable to the indended course (we can use caching to make this efficient).

  3. We’re introducing more complexity in terms of how subsidized enterprise enrollments can come into existence.

  4. The realization model makes the provenance of default enrollments explicit and easy to examine.