Student Lifecycle Data in Saudi Institutions: Admission to Alumni, One Record

For registrars, deanship of admission and registration staff, and IT directors at Saudi universities and colleges. This is a data-architecture guide, not a policy summary. By the end you should be able to name, for each lifecycle stage, the record that must exist, who owns it, which identifiers have to reconcile, and where the same fact is stored twice and quietly diverging.

The stages, and the record that must exist at each

One rule governs all seven stages: a fact is entered once, at the stage that owns it, and every later stage reads it rather than re-keying it. The moment it is re-keyed, you have two versions and no rule for which wins.

Stage	Record that must exist	Owner	Identifiers that must reconcile	Where it drifts
Enquiry	Prospect record with contact details and intended programme	Admissions or marketing	Mobile number, email; no national ID yet	Duplicate prospects created per campaign; never merged to the eventual applicant
Application and admission	Application with secondary certificate, Qiyas scores, programme preferences, decision and decision date	Deanship of Admission and Registration	National ID or Iqama, unified admission reference, secondary certificate number	Name and date of birth typed locally instead of taken from the admission feed
Registration	Enrolment record: term, programme and plan version, section, credit load, status	Registration	University number issued and bound to national ID or Iqama	Programme code changes at plan revision and splits one cohort across two codes
Progression	Status history: active, postponed, withdrawn, dismissed, transferred, re-enrolled	Registration	University number, plan version	Postponement recorded as withdrawal, which breaks retention
Assessment	Course result per student per section, with grade symbol and points	Faculty, confirmed by registration	Course code, section, plan version, outcome mapping	Pre-moderation mark in the LMS, post-moderation mark in the SIS
Graduation	Award record: degree, major, final grade, date of granting, in Arabic and English	Registration and the college	University number and national ID or Iqama both printed	Arabic name from the ID, English name from a form filled by the student
Alumni	Alumni record with destination, employer and consent basis	Alumni office or careers	National ID or Iqama as the join key back to the student record	Alumni system keyed on email, so the join to the graduating cohort is lost

Read the last column as a defect list. Every entry in it is a specific, fixable data condition, and each one shows up later as a number a reviewer will ask about.

Identifiers: which one is the spine

Three identifiers matter and they do different jobs.

The national ID or Iqama number is the person. It is the only identifier that survives a change of institution, a change of name or a gap in study, and it is the key you use to join to anything outside the university.

The university number is the enrolment, not the person. Saudi study and examinations regulations allow a dismissed student to apply again after four semesters as a new student, with the application treated without reference to the previous record. Read literally, that produces one human being with two university numbers, two academic histories and no link between them unless you deliberately maintain one. Key the person record on national ID or Iqama, and hang university numbers off it as enrolment instances.

The unified admission reference is the transaction. The Ministry of Education operates Unified University Admission through the National Unified Admission Platform for entry to public universities and technical colleges, with applicants ranking programme preferences and confirming nominations through the portal. If your SIS does not store that reference, you cannot prove which admission cycle a student arrived through, and you cannot reconcile your intake against the platform's.

Two rules. Store the identifier type alongside the number, because national ID and Iqama occupy the same field in most Saudi systems and a student who converts status will change number; keep the old value with an effective date rather than overwriting it. And never derive nationality, gender or eligibility from the identifier itself. That derivation rule ends up inside one report, wrong for one category of student, with nobody able to say where the number came from.

[NEEDS SOURCE: the number-range conventions distinguishing Saudi national ID numbers from Iqama numbers are widely implemented but no official specification could be retrieved. Confirm the format and prefix rules from the Ministry of Interior or the National Information Center before encoding a validation rule]

[NEEDS SOURCE: identity verification through Nafath, Absher and Tawakkalna is standard for Saudi government service access, but the service specification, the attributes returned to a subscribing entity, and eligibility for higher education institutions could not be retrieved. Confirm with the service owner before designing an integration]

Arabic and English names are not two spellings of one field

This is where most systems imported into this market fail, and the failure is architectural rather than cosmetic.

The Arabic name is authoritative: it is the name on the national ID, on the secondary certificate, and on the degree, and it is conventionally four parts, given name, father's name, grandfather's name and family name. The English name is a transliteration, and there is no single correct transliteration. The student writes one on the application, the passport office produced another, the previous institution used a third.

The consequences are concrete. A student called محمد appears as Mohammed on the transcript, Mohamed on the certificate and Muhammad in the alumni system, and three exact-match joins fail. A four-part Arabic name loaded into a first name and last name pair loses the middle two parts, so the degree prints a name the graduate cannot use for attestation. Sorting an Arabic list under English collation produces an order the registry will not accept.

What to do:

• Store the Arabic name in four discrete fields, not one concatenated string, and treat it as the source of record.
• Store the English name separately in the same four-part structure, with a flag for whether it was verified against the passport.
• Never generate the English name by automatic transliteration for a document that leaves the institution.
• Join on the identifier, never on the name. Name matching is for review queues only.
• Test rendering both ways: an Arabic name inside an English sentence is a bidirectional text problem, and a PDF engine that handles it in preview but not in print is common.

Hijri and Gregorian dates, stored as a pair

Regulations, ministerial decisions and much internal correspondence carry Hijri dates; academic calendars, international partners and most software carry Gregorian.

Store one canonical date and derive the other, never both as free text. Choose Gregorian as the stored value because it is unambiguous and sortable, and derive the Hijri display through a single conversion service used by every module. Otherwise you get a date that is right on screen and wrong in the export, or a Hijri date entered as a Gregorian one so a birth date lands centuries out and passes validation.

Three traps:

• The academic year label. A year written as 1447 in one report and 2025/26 in another is the same year, and a reviewer comparing two of your documents cannot tell.
• Month boundaries. A conversion library shipped with an application may disagree with the calendar in official use by a day. Any deadline computed in Hijri and enforced in Gregorian needs a documented conversion source.
• Age and eligibility rules. A rule expressed in Hijri years applied to a Gregorian date of birth drifts by roughly eleven days a year.

[NEEDS SOURCE: the official status of the Umm al-Qura calendar and the body responsible for issuing it could not be confirmed from a primary source during research. Confirm the authoritative conversion reference before implementing date conversion]

Where the same fact gets stored twice

Five places, in rough order of how much trouble each causes.

The mark. The LMS gradebook holds the working mark; the SIS holds the confirmed mark after moderation. Both are legitimate. A transcript generated from whichever was queried is not. Make the SIS the system of record for confirmed results and the LMS read-only for them after release.

Student status. Registration holds enrolment status, finance holds a payment status, and the portal holds a third derived from the other two. A student who has postponed but not settled fees is active in one and inactive in another, and the retention figure depends on which was asked.

Programme and plan. The programme code sits on the student record and on the study plan. When the plan is revised the student stays on the old plan, but the code is often overwritten, which silently moves the whole cohort.

Contact details. Updated in the portal by the student, in the SIS by registry, and in the alumni system after graduation. Without a single owner and a last-updated timestamp, the graduate destination survey goes to an address three years old.

The cohort. Every report that says "the 2023 intake" defines it again. Define it once, in a definitions register, with a census date attached.

Transcripts and certificates in two languages

The graduation document is the highest-consequence output the system produces, and where all the earlier decisions surface at once.

Saudi undergraduate study and examinations regulations, as published in institutional implementations, require the graduation document to state the graduate's full name, university number, ID or residence number, college, degree, major, final grade and date of granting, in Arabic and English. Records show all courses studied, credits earned, semester and cumulative grade point average, and academic warnings, and credits recognised on transfer appear on the record without entering the grade point average calculation.

That last clause is a generation rule, not a footnote. If transferred credit is loaded as ordinary results, the printed cumulative average will not match the one the regulation defines.

The grade symbol set is the second trap. Non-numeric symbols sit alongside letter grades: IC for incomplete, IP for in progress, W for withdrawal, and DN where a student is denied entry to the final examination for falling below the attendance threshold, which carries a fail outcome. Each needs an explicit rendering in both languages and an explicit rule for whether it enters the average. A transcript that prints a blank where DN belongs misrepresents the record.

Grade point scales are the third. Saudi institutions publish both five-point and four-point scales, and honours thresholds are expressed against the scale in use. A cumulative average stated without its scale is not interpretable outside the institution, and a warehouse that mixes the two produces averages that mean nothing.

[NEEDS SOURCE: the canonical text of the Council of University Affairs Study and Examinations Regulation for the undergraduate stage, including the authoritative grade scale, symbol set and article numbering, could not be retrieved from cua.gov.sa. The detail above is drawn from a published institutional implementation of that regulation. Verify against the Council text before relying on any specific article]

What the reporting pulls through

Two destinations, and they want the same underlying records in different shapes.

NCAAA and ETEC. Accreditation review is evidence-led: the Academic Accreditation Policies require conclusions to rest on directly observable evidence, and the programme standards expect self-assessment against key performance indicators with internal and external benchmarks. In lifecycle terms: admission criteria and the applicant-to-enrolment funnel, cohort progression and completion with a stated cohort definition, grade distributions by course, the grade-change audit trail, graduate destinations with a known survey coverage rate, and student records with retention and access controls. None of it is a separate exercise. All of it is the lifecycle record, sliced by cohort and frozen at a census date.

Ministry of Education and Council of University Affairs returns. The Ministry publishes higher education statistics and open data annually, and the Council of University Affairs publishes a university and student statistics dashboard. Both rest on institutional submissions.

Admission-side data arrives from outside as well. Aptitude and achievement test results are issued by the National Center for Assessment (Qiyas) under ETEC and keyed to the national ID. Load them against the person record with the issuing date, not against the application, so a later application can reuse them.

[NEEDS SOURCE: the field-level specification, submission channel and deadlines for institutional statistical returns to the Ministry of Education and the Council of University Affairs could not be retrieved, and nor could the validity period of Qiyas test results. Obtain both before mapping SIS fields or building an expiry rule]

A data-reconciliation procedure

Run this before an accreditation submission, before an annual statistical return, and once a year regardless.

1. Build the person index. One row per national ID or Iqama number, listing every university number, application reference and alumni record attached to it. The exceptions report is your duplicate list.
2. Resolve duplicates by identifier, not by name. Route name-only near-matches to a human queue, and record every merge with a timestamp and an operator.
3. Freeze census dates and publish them. One enrolment census per term, one cohort census per intake, one staffing census per year.
4. Snapshot rather than query. Write each census to an immutable store with the definition version attached, so a report produced next year reproduces exactly.
5. Reconcile intake against the admission platform. Match registered intake to the unified admission nominations for the same cycle, and account for every difference: declined offers, deferrals, late admissions, direct entries.
6. Reconcile status codes against the regulation. Every SIS status maps to exactly one regulatory concept: postponement, withdrawal from a course, withdrawal from a term, academic dismissal, denial of examination entry, re-enrolment. Anything mapping to two is why your retention numbers move.
7. Reconcile marks between the LMS and the SIS for a sample of sections per term, and confirm the SIS value is the post-moderation one.
8. Reconcile the printed transcript against the stored record. Take ten graduates, regenerate both language versions, and check name parts, symbol rendering, transfer credit exclusion, grade scale statement and both calendar dates.
9. Reconcile alumni to the graduating cohort on the identifier and record the match rate. That rate is the coverage figure for any destination statistic you report.
10. Log the exceptions you did not fix, with an owner and a date. A dated list of known differences is defensible. A silent difference found by a reviewer is not.

Where teams get this wrong

The system is configured in English and Arabic is added afterwards. Templates, collation, name structure and report layouts all assume one direction of text. Retrofitting costs more than configuring for both at the start.

Retention is computed from a live query. It returns today's numbers, changes every time it is run, and the trend the quality deanship reports cannot be reproduced.

The alumni system is bought separately and keyed on email. The join back to the academic record becomes a name match, and destination reporting coverage cannot be stated honestly.

Plan versions are not modelled. A curriculum revision rewrites the requirements, students admitted before it are audited against rules that did not exist when they enrolled, and graduation checks fail for a whole cohort at once.

Nobody owns the definition of an active student. Registry, finance and the quality deanship each have a working answer, all three appear in the same self-study, and a reviewer finds all three in a morning.

What to automate, and what not to

Automate the mechanical layer: identity resolution on the national ID or Iqama with a review queue for ambiguous cases, census snapshots written to immutable storage, status-code validation against the regulation, bilingual document generation from stored fields rather than a template someone types into, calendar conversion through one service, and scheduled reconciliation reports that produce an exceptions list rather than a green tick.

Do not automate the merge decision on ambiguous records, and do not automate anything that changes a confirmed grade. A merge that joins two people because their Arabic names match is a data breach and an academic record failure at once. Grade changes need a named approver and an audit trail, because the audit trail is itself accreditation evidence. Automation removes the excuse for inconsistency, not the people.

Where a system helps

The workflow a higher education ERP should carry is specific: a person record keyed on the national ID or Iqama with university numbers as enrolment instances under it, four-part Arabic and English names as structured fields, one canonical date with derived Hijri display, plan versions modelled so a cohort stays on the plan it was admitted to, and census snapshots that make every reported figure reproducible. Everything downstream, accreditation evidence and statistical returns included, is a query over that. That is what CampusOS is built to do. More on our higher education solutions page.

FAQ

Should the university number or the national ID be the primary key? The national ID or Iqama identifies the person; the university number identifies an enrolment. Key the person record on the former, or a returning student becomes two people.

How do we handle a student whose Iqama becomes a national ID? Keep both values with effective dates on the same person record rather than overwriting. Documents issued before the change carry the old number and still have to be verifiable.

Which calendar should be stored? Store Gregorian and derive Hijri through a single conversion service. Storing both as entered fields guarantees they disagree within a year.

Can the English name be generated automatically? For internal screens, yes. For anything that leaves the institution, no. A degree certificate whose English name differs from the passport creates an attestation problem for the graduate.

What is the fastest way to find out how bad our data is? Run step one. Count the national ID values holding more than one university number, and the university numbers holding no national ID at all. Those two counts predict almost every downstream reporting problem.

Related reading: What Is NCAAA? Saudi Arabia's Academic Accreditation Body, Explained (KB-003), and ETEC and NCAAA Accreditation: The Data Institutions Must Be Able to Produce (KB-004).

Sources

• Council of University Affairs, Study and Examinations Regulation for the Undergraduate Stage
• Saudi Electronic University, Rules and Regulations of Undergraduate Study and Examinations
• Ministry of Education, Unified University Admission
• Ministry of Education, Open Data
• Council of University Affairs, University and Student Statistics
• ETEC / NCAAA, Academic Accreditation Policies (Policy Book)
• NCAAA, Standards for Program Accreditation
• ETEC, National Center for Assessment (Qiyas)
• Bureau of Experts at the Council of Ministers, Higher Education Council and Universities Law