Enrollment

  1. Overview
  2. Hand Off Documentation
  3. User Mgmt & Enrollment
  4. Enrollment

Feature Owner: Joshua Uriel Tribiana
Module: User Mgmt & Enrollment
Priority: P1
Week 5 Sprint: Implemented in Current Codebase
Date: 07-01-2026

EXECUTIVE SUMMARY

What is this feature?
Enrollment is the access-control and onboarding layer that connects learners to quests. It allows creators to invite or assign learners to a quest, track their progress, and manage their participation, while learners can self-enroll into published quests.

Why does it matter?
Enrollment is the system boundary between “content exists” and “a learner can actually access and progress through it.” Without a reliable enrollment model, quests cannot be assigned, tracked, or completed in a structured way.

What’s the MVP scope?
The current implementation includes:

  • Creator-side learner management for a quest

  • Manual add and bulk import of learners

  • Learner self-enrollment into published quests

  • Enrollment progress and status tracking

  • Enrollment deletion and status updates

1. USER PAIN POINT & SOLUTION

Current State (Without Feature)

A quest may be published and complete, but there is no structured way for creators to assign or manage participation or for learners to enter the experience in a tracked, persistent way.

Pain Point

  • Emotional: Frustration when learners cannot access or be tracked in a quest experience

  • Functional: No reliable access-control or progression mechanism for assigned quest participation

  • Business Impact: Weak adoption, poor tracking, and no clear learning journey ownership

Future State (With Feature)

Creators can manage who is enrolled, learners can self-enroll into available quests, and the system can track each learner’s status and progress inside the quest.

Marketing Hook

“Turn published quests into guided learning journeys with structured enrollment, progress tracking, and learner management.”

2. CODEBASE ASSESSMENT

Current Implementation Status

Enrollment is implemented through a creator management page plus learner-facing enrollment APIs and progress hooks.

Primary Files

Current Behavior Summary

  • Creators can manually add learners to a quest by email

  • The creator enrollment page shows learner status, date enrolled, progress, and actions

  • Learners can self-enroll into published quests

  • Enrollment data is stored in the quest_enrollments table and linked to app_users

  • Progress is stored as a JSON payload with percentage and visited-card metadata

Strengths Already Present

  • Strong creator management workflow for learners

  • Enrollment creation is guarded by role and ownership checks

  • Self-enrollment is idempotent and prevents duplicates

  • Progress and status are tracked per learner and quest

Gaps / Hardening Opportunities

  • Enrollment count updates are not yet fully synchronized in some flows

  • The current UI uses direct prompts for custom progress editing rather than a more structured modal

  • The system currently relies on role and ownership checks but could be expanded with richer gating rules such as enrollment limits or paid access validation

3. 4D FRAMEWORK MAPPING

Diagnose

Learners need structured access to quests, and creators need a way to manage participation and track progress.

Design

Enrollment is modeled as a first-class relationship between learners, quests, and progress state, surfaced through both creator and learner experiences.

Develop

Creators can add and manage learners, while learners can access quests once enrolled and progress is tracked automatically.

Deliver

A quest becomes a structured learning experience with persistent learner state and progress visibility.

4. USER FLOWS

Entry Point

A creator opens the Enrollment tab for a quest, or a learner visits a published quest and chooses to enroll.

Success Criteria

  • The learner becomes associated with the quest

  • The creator can see the learner in the enrollment list

  • The learner’s progress and status are tracked

Main Flow (Happy Path)

  1. Creator opens the quest enrollment page

  2. Creator adds a learner by email or imports a batch

  3. The system verifies the learner account and creates an enrollment record

  4. The learner receives an enrollment notification email

  5. The learner can access and begin the quest

  6. The creator can update the learner’s status and progress over time

Edge Cases

  • Learner already enrolled: The system returns a conflict or success without duplicate record

  • Learner account missing: The creator gets a clear error and cannot enroll until the account exists

  • Wrong role: Only LEARNER accounts are accepted

  • Progress update invalid: The system caps progress to 0–100

Decision Points

  • IF the learner is already enrolled → no duplicate entry is created

  • IF the quest is not published → self-enrollment is rejected

  • IF the creator removes an enrollment → the learner loses access to that quest’s tracked progress relationship

5. INFORMATION ARCHITECTURE

Primary Information (Always visible)

  • Learner name and email

  • Current status (ongoing or finished)

  • Date enrolled

  • Progress percentage

Secondary Information

  • Completed task count or progress detail metadata

  • Action menu for progress and removal actions

Tertiary Information (Hidden until needed)

  • Internal JSON progress payload

  • Enrollment IDs used for management actions

Actions

Primary CTA:

  • Add Learner / Bulk Import

Secondary Actions:

  • Mark as finished or ongoing

  • Reset progress

  • Remove enrollment

6. WIREFRAMES

The experience is embedded in the quest editor’s enrollment section.

Key Screens:

  1. Enrollment dashboard with learner table

  2. Add learner modal

  3. Bulk import modal

  4. Confirmation modal for removal

Annotations:

  • Enrollment is managed per quest

  • Status and progress are visible in a table view

  • Actions are grouped around learner administration

7. WIREFLOWS

Creator opens enrollment → adds or imports learner → learner is enrolled → creator monitors progress → status or progress updates are applied

8. PROTOTYPE

Figma Prototype Link: Not currently available for this feature

How to test:

  1. Open a quest in the editor and visit the Enrollment section

  2. Add a learner by email

  3. Confirm the learner appears in the table with an ongoing status

  4. Update their progress or mark them finished

  5. Remove the enrollment and verify it disappears

9. DATA MODEL

Core Table

The feature depends on the quest_enrollments table with the following concepts:

  • quest_id

  • learner_id

  • status

  • progress

  • enrolled_at

Progress Shape

Progress is stored as a JSON object with fields such as:

  • percentage

  • visited_cards

  • last_visited_at

Relationship to Users

Enrollment records are linked to app_users for the learner identity and email display.

10. API CONTRACTS

Creator Create Enrollment

Endpoint: POST /api/creator/enrollment/create-enrollment

Request:

 
{
  "quest_id": "uuid",
  "learner_email": "learner@example.com"
}

Behavior:

  • Validates quest ownership

  • Verifies the learner exists and is a LEARNER

  • Prevents duplicate enrollments

  • Inserts a new quest_enrollments record

  • Sends an enrollment email

Creator List Enrollments

Endpoint: GET /api/creator/enrollment/list-enrollments?quest_id={questId}

Behavior:

  • Returns enrollments and related learner data for the specified quest

Creator Update Enrollment

Endpoint: PUT /api/creator/enrollment/update-enrollment

Request:

{
  "enrollment_id": "uuid",
  "quest_id": "uuid",
  "status": "finished",
  "progress": 75
}

Behavior:

  • Updates status and/or progress

  • Caps progress to 0–100

Creator Delete Enrollment

Endpoint: DELETE /api/creator/enrollment/delete-enrollment

Request:

{
  "enrollment_id": "uuid",
  "quest_id": "uuid"
}

Behavior:

  • Removes the enrollment from the quest

Learner Self-Enrollment

Endpoint: POST /api/learner/enroll

Request:

{
  "quest_id": "uuid"
}

Behavior:

  • Requires a published quest

  • Prevents duplicate enrollments

  • Creates an enrollment record for the authenticated learner

11. DATA REQUIREMENTS

Frontend Needs

The creator page needs:

  • The list of enrollments for a quest

  • The ability to add, update, and delete them

  • Visibility into progress and status

Learner Needs

The learner self-enrollment flow needs:

  • Access to a published quest ID

  • A valid authenticated learner account

  • A safe idempotent enrollment path

12. SECURITY & AUTHORIZATION

Who can access this feature?

  • Creator: ✓

  • Learner: ✓

  • Reviewer: ✗

Authorization Logic

  • Creator routes verify that the quest is owned by the authenticated creator

  • Learner self-enrollment requires an authenticated learner account

  • Only existing LEARNER accounts can be assigned to a quest

13. ERROR HANDLING

Common Errors

  • Missing quest or learner email

  • Learner account not found

  • Learner already enrolled

  • Quest not published for self-enrollment

  • Invalid progress value

Handling Guidance

  • Return clear status and message payloads to the UI

  • Keep the UI responsive by updating local state after successful mutations when possible

14. TESTING CHECKLIST

Happy Path

  • A creator can add a learner to a quest

  • The learner appears in the enrollment table

  • The creator can update progress and status

  • The learner can self-enroll into a published quest

Edge Cases

  • Duplicate enrollment is prevented

  • Non-LEARNER accounts cannot be enrolled

  • Missing or invalid inputs return proper errors

  • Progress is capped correctly between 0 and 100

15. OPEN QUESTIONS

For Product

  • Should enrollment limits or paid gating be added to the flow?

  • Should creator-invited learners receive a richer onboarding experience after enrollment?

For Engineering

  • Should the creator enrollment page eventually support richer bulk operations import?

  • Should enrollment counts be updated more systematically across the app?

16. OUT OF SCOPE (v1.1+)

Not in the current implementation:

  • Automated seat management or paid enrollment gating

  • Advanced cohort-based enrollment rules

  • Full analytics dashboards for cohort activity

17. SUCCESS METRICS

How will we know this feature is working well?

  • Learners are successfully added to quests and start their learning journey

  • Creators can manage participation without manual workarounds

  • Progress and completion state are visible and reliable

18. DEPENDENCIES

This feature depends on:

  • The quest_enrollments data model

  • The creator authentication layer

  • The learner authentication layer

  • The quest publishing state

These features depend on this:

  • Quest progression and completion tracking

  • Learner dashboards and quest access flows

19. TIMELINE & OWNERSHIP

Implementation Ownership

  • Ownder: Joshua Uriel Tribiana

  • QA: Joylynne Esportuno ( teruterubozuuu )

Written by Uriel Last updated June 30, 2026
Was this article helpful?