ERP integration
In developmentHow LEAP and your ERP divide responsibility, what moves between them, and what your ERP team is being asked to provide.
This documents an agreed architecture whose contract is still being finalised with the first institution’s ERP vendor. No data currently moves between LEAP and any ERP. Read it as a design to review, not a feature to switch on.
Every piece of information has exactly one home. It is created and edited in one system only; the other system holds a copy it never edits. A course created in the ERP appears in LEAP automatically. Marks earned in LEAP appear in the ERP automatically. Nothing is entered twice, and there is never a question of which screen holds the correct version.
Two systems, two jobs
The system of record
Holds what the institution must be able to prove: who was enrolled, what they studied, what they scored, what the calendar was. Authoritative and audited, because these records may be re-examined years later by an accreditor or regulator. Its correctness matters more than its convenience.
The system of engagement
Where teaching and learning actually happen: a student opening a lesson at 11pm, asking a doubt, taking a practice quiz, seeing where they stand. It changes constantly, because its usefulness depends on how fast it can improve.
Both exist for a reason. An ERP built to iterate quickly stops being safe to audit; a learning platform built to be audit-stable stops being useful to teach with. The ERP is the institution’s memory; LEAP is its classroom.
What each system owns
Read the badge first. It tells you which system creates and edits the row; everything else follows from that.
LEAP has working modules for both. Under this design they become mirrors of the ERP.
Duplicated ownership of the academic calendar is exactly the problem being solved, so this is conceded on purpose.
LEAP sends raw marks and percentages. Converting those into a final grade — weighting, moderation, any grace policy — stays with the ERP.
Grading policy is an institutional rule, not a software feature.
How information flows
- ERP/LEAP
- 1Course shell — ERP → LEAP
- 2People + enrolment — ERP → LEAP
- 4Marks + status — LEAP → ERP
- 5Signed sign-in token — ERP → LEAP
- Within LEAP · Lessons, materials, quizzes, AI tutor, remediation, voice feedback, engagement analytics
Course setup
ERP → LEAPAn administrator creates the course shell in the ERP exactly as they do today. Within minutes it appears in LEAP. Nobody creates it a second time.
The shell arrives, but the course is not yet ready to teach. Faculty still upload the syllabus, and LEAP generates lesson structure, assessments and materials for their review. No AI-generated content reaches a student without a faculty member approving it. The ERP creates the container; the teaching content is built and approved inside LEAP.
People and enrolment
ERP → LEAPContinuous. A student enrolled in the ERP gains LEAP access automatically; a student who withdraws loses it.
Earlier work is preserved rather than deleted, so the record stays complete for audit.
Teaching and learning
Within LEAPLessons, materials, quizzes and exams — online or on paper via scanned answer sheets — AI tutor doubts, personalised remediation, voice feedback calls, sentiment and engagement analytics.
None of this touches the ERP. It is learning activity, not institutional record.
Results
LEAP → ERPAs assessments complete, LEAP sends marks against the correct student and course. No spreadsheet, no manual re-keying at term end, which is where transcription errors are most commonly introduced.
Marks carry a status so the ERP can distinguish provisional results from faculty-signed-off finals.
Access
ERP → LEAPLinks to LEAP inside the ERP, so the ERP stays the familiar front door and LEAP opens directly at the right course.
Ideally carrying a short-lived signed token, so users are signed straight in rather than meeting a second login screen.
What this does not change
The ERP remains the authoritative record. Nothing official is held only in LEAP.
Every mark LEAP produces is written back and becomes an ERP record.
The ERP is not replaced, reduced or modified. No module is retired, no workflow changes.
What your ERP team provides
- 1Read access to academic data the ERP already holds — courses, students, faculty, enrolments — through a read-only service account.
- 2One endpoint that receives assessment marks from LEAP.
- 3A stable, permanent identifier for each person and each course, so the two systems stay correctly matched over time.
- 4Links to LEAP placed in the ERP interface, ideally carrying a secure sign-in token.
Timetable, attendance and marking schemes follow in a later phase, once the initial flow is proven.
Phasing and open questions
Which system owns approved course outcomes, and who produces attainment reporting?
LEAP derives outcomes from the syllabus and computes attainment.
The ERP holds an approved outcome set and LEAP takes it from there.
Recommended. If the ERP already holds an approved outcome set, LEAP should read it from there, so there is only ever one accreditation record.
Where does the attendance boundary sit?
LEAP writes to the official register.
The register stays entirely the ERP's; LEAP surfaces engagement signals separately as advisory information.
Recommended. The second. LEAP never writes to the register. It surfaces who opened lessons, who sat assessments, and feedback gathered during voice calls — including disputes of an attendance record — clearly marked as advisory and distinct from the official register.
This design reflects information available today. As the integration meets day-to-day use, some approaches may need adjusting. The principle — one home for every piece of information — is what stays constant; the mechanics may evolve.