# Course Access and Assessment in a Single Student Record Education | MT BYTES solution study A connected student record links enrolment, course access and assessment, preserving academic history when a programme changes or a student defers. The learning platform connects admission, payment and teaching records through the student's enrolment. Course access follows the relevant enrolment decision, while assessment requirements and completed work remain visible throughout the programme. Deferrals and programme changes preserve earlier academic history. Students receive the next task and staff retain the evidence needed to explain or correct the record. ## Solution design ### Students can see what is ready and pending The student portal carries enrolment tasks, course access and assessment requirements through the programme. Staff can trace an access problem to the decision or system holding it up, while academic approval remains separate from payment and administrative activity. - Course access matches the approved enrolment - Transfers preserve completed academic work - Completion records have a reviewable basis **Business context:** An education provider running cohort-based professional programmes with live classes, online coursework and formal assessments. **Core capability:** Software Development ![Solution study artwork](../../images/solution-studies/selected/11-hero.webp) ## Scope - Application-to-enrolment record mapping - Student identity and course access rules - Learning platform and payment integrations - Student portal and enrolment support workspace - Assessment completion and exception records ## Acceptance is only the start of course access A student can have an acceptance email and a paid invoice without being able to open the first lesson. Admissions, finance and the learning platform each hold a valid part of the story, but none can explain the whole problem. Staff end up checking inboxes and adding course memberships by hand. The platform puts that handoff on a student record. It shows which enrolment conditions are satisfied, what access has been requested and whether the learning system has confirmed it. The same record supports returning students, deferred places and programme changes, instead of treating each exception as a new account. ## One person can have several enrolments Identity, application, enrolment, cohort and course membership are separate records. This matters when a student returns for another qualification or moves to a later start date. Their identity stays the same while the rules governing a particular programme change. Email addresses help with communication; they are not sufficient proof that records should be merged. The enrolment rules distinguish academic acceptance from financial conditions. A sponsor-funded place may need different checks from a self-funded one. A refund can trigger a review without automatically withdrawing the student. Every consequential transition records the deciding role, effective date and reason, giving support something more useful than an active or inactive flag. ## The learning platform keeps its teaching responsibilities Course materials, submissions and assessment activity stay in the learning management system. The new layer holds enrolment rules and the relationship between the student's records. Adapters exchange specific events, such as confirmed enrolment or an approved assessment result, without copying the teaching system's entire database into another application. Each incoming event carries a source identifier and a processing record. A repeated payment notification cannot grant access twice. Failed requests remain available for retry, and a reconciliation job compares expected memberships with those actually present. Until the learning system confirms access, the portal shows it as pending and gives staff the reason. ## The next task changes as the programme progresses Before the start date, the portal shows outstanding documents, orientation information and the course release date. During teaching, the emphasis moves to the next session, assessment deadlines and messages relevant to that enrolment. After approval of completion, the student can retrieve the current certificate or record and see which materials remain available. Progress labels distinguish attendance, content viewed and assessed work. Watching every lesson does not complete a programme that requires an approved submission. Each unfinished requirement links to the action needed, including an extension request where permitted. Forms retain draft work, explain errors beside the affected field and remain usable with a keyboard or small screen. ## A deferral changes the plan without losing the history An approved deferral moves future participation to another cohort while retaining the original enrolment and any recognised assessment evidence. Transfers apply the destination programme's requirements rather than assuming that every completed activity carries over. Academic staff approve exceptions; financial consequences create a separate finance task instead of silently changing the account balance. Permissions follow those responsibilities. Tutors can review relevant submissions without browsing payment documents. Finance can resolve enrolment conditions without unrestricted access to assessed work. Support can inspect entitlement failures without signing in as the student. Uploaded documents have defined retention rules, and corrections retain the earlier decision and the reason it changed. ## The first release follows one programme all the way through The initial release covers an accepted application, confirmed enrolment and usable course access for one programme. Checks include duplicate notifications, a delayed learning-system response, withdrawal and deferral. Staff also rehearse the recovery actions, because an access error that only an engineer can diagnose leaves the admission team with the same bottleneck. Migration compares existing people, enrolments and memberships before granting new permissions. Uncertain matches go to review. A parallel comparison exposes disagreements between old and new entitlement rules without immediately changing student access. Each additional programme joins with its own completion requirements, access periods and named academic owner. ## Programme changes have consequences beyond the course page Changing an assessment or access period affects students already enrolled. Programme updates therefore identify which cohorts follow the new rules and which retain the previous version. Academic leadership approves requirements, student services prepares the communication and engineering checks the effect on access and integrations. The effective date travels with the change. Support cases link to the enrolment and the failed step. Repeated questions about when lessons open call for clearer wording; repeated membership mismatches call for an integration fix. Runbooks cover event replay, approved record correction and verification in the teaching system. Staff can resolve a routine problem without relying on whoever last handled it. ## Participation and academic achievement stay distinct Access time runs from completion of the required enrolment conditions to verified membership in the learning platform. Time waiting for an academic decision is reported separately from technical delay. Reconciliation records show unexpected memberships as well as missing ones, so the service cannot appear healthy merely because every student can log in. Assessment reporting keeps programme requirements and cohort differences in view. The operational questions are specific: can the student reach the right course, understand the work still due and obtain the correct completion record? Access-related support cases and reopened enrolment problems show where that chain still needs attention. ## Operational flow 1. **Application.** Record the programme choice and the evidence needed for admission. 2. **Enrolment decision.** Resolve academic and financial conditions under the appropriate authority. 3. **Course access.** Request membership and verify it before showing the course as ready. 4. **Assessment review.** Record approved results, extensions and requirements still outstanding. 5. **Completion record.** Issue the approved record and apply the continuing access rules. ## Key decisions ### Retain the teaching platform Course delivery and assessment remain in the existing learning system. The new platform addresses enrolment and access without forcing tutors to replace established teaching tools. ### Separate enrolment from payment Academic and financial conditions have distinct decisions and owners. Sponsorship, refunds and deferrals need more precise handling than a paid or unpaid label. ### Check actual memberships Reconciliation compares required access with the learning system's records. An accepted integration request does not confirm that the student can open the course. ## Evaluation measures These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks. ### Delay before usable course access **Measure:** Compare prerequisite completion with confirmed course membership, separating decision waits from integration failures. **Success criteria:** Students whose enrolment is complete can start without an avoidable support request. ### Incorrect course memberships **Measure:** Review missing and unexpected memberships by programme and cause. **Success criteria:** Access corrections address the underlying rule or integration fault. ### Repeated enrolment enquiries **Measure:** Link support contacts to the enrolment and the question or failed step. **Success criteria:** Students receive an answer that resolves the problem without repeating their history. ## In practice The student record gives each department a defined part of the same programme. Admissions can confirm the place, finance can resolve its conditions and tutors can assess the work without borrowing one another's status labels. For the student, those distinctions appear as something simpler: the right course, the next task and an accurate record of what they have completed.