Merge Duplicate Students

Use the merge workflow when two student records belong to the same person and their enrolments, payments, communications, assessments, and compliance history need to appear under one record.

Access required

Choose the task you are doing. Each row is a separate action.

Before you merge

Confirm the records refer to the same person using reliable identity evidence such as their name, date of birth, USI, email, mobile number, and original booking history.

Older records need context. USIs only became mandatory for nationally recognised training on 1 January 2015, so some earlier students legitimately have none, while older datasets, especially records from before 2012, may contain missing, shared, family, workplace, or another person's email address. Do not merge merely because two students share an email.

Review potential duplicates

Open Students → Potential duplicates to review active student pairs in one table. RTObase compares:

• exact USIs and driver licences
• exact or similar names with the same date of birth
• normalized mobile, home, and work phone numbers
• primary and additional email or phone contacts

Each row explains why the students matched and distinguishes strong matches from records that need manual review. Email-only matches are deliberately marked as weak evidence. Select Review merge to open the merge wizard with the pair preselected; no records change from the table alone.

Merge records

The merge dialog is a three-step wizard. Up to ten records can be merged in one action.

What the merge changes

RTObase creates one new active student and:

• moves student-owned enrolments, payments, communications, assessments, contacts, and related records to it
• retains distinct source primary emails and phone numbers as labelled additional contacts
• inherits the selected canonical source's effective AVETMISS Client Identifier
• archives every original source record and links them to the merged record
• records the original owner of every moved row so a safe reversal can restore it exactly
• writes a MERGE audit event and student activity events

The merge does not change an enrolment's class, course, dates, outcomes, payment amounts, or document issue-time snapshot. Audit rows and historical lodgements are not rewritten; the merged record displays the related source and merge history together.

When a merge is blocked

RTObase fails closed when it finds evidence that requires human resolution, including:

• different non-empty USIs or dates of birth
• more than one linked student-portal account
• two or more reportable enrolments in the same course across the selected records
• one of the selected records has already been merged
• child records that would violate a unique constraint
• a non-canonical AVETMISS Client Identifier that was already lodged

A reportable enrolment here means a non-archived, non-LLN-gated enrolment on an accredited course, the same records AVETMISS reporting draws on. Because a merge has no reporting period, RTObase cannot check whether the units fall in the same period, so this rule is deliberately conservative: it can surface a pre-existing same-course duplicate the merge itself did not create. Resolve or archive the extra enrolment first. RTObase never silently archives one for you.

If issued completion documents exist, the administrator must separately confirm that the issue-time evidence chain has been reviewed. Existing documents retain their issue-time student snapshot.

Reverse a recent merge

For 30 days after a merge, the merged student's More actions menu includes Reverse merge. Type UNMERGE to confirm. Once the 30-day window closes the option is withdrawn and the merged record becomes an ordinary student again.

A reversal deletes the synthetic merged record, restores every archived source, and returns each provenanced row to its exact original owner (additional contacts created by the merge itself are removed).

The reversal fails closed. If the merged record has gained any new timeline activity since the merge, such as a new enrolment, payment, assessment, note, or a verification, identity, LLN, or survey event, RTObase blocks the reversal rather than guess which source should receive it. It never deletes that activity to force a reversal through; you keep the merged record and resolve it manually instead. Only the two internal breadcrumbs the merge itself wrote (the "records merged" marker and the new record's own creation event) are cleaned up when a reversal does proceed.

The merge and reversal audit history is always retained.

Keep going