Skip to main content
All CollectionsApplications - PassiveCreating your API Integration
Passive Applications - Student Matching Rules
Passive Applications - Student Matching Rules

When an application is submitted to an APV occurrence, how does it match to an existing student record?

Laura Montgomery-Hurrell avatar
Written by Laura Montgomery-Hurrell
Updated over 3 months ago

When a new application is submitted via the API from your SRS, Student CRM will use the student's details to try and match with an existing student record in your database.

This means you can track an enquirer turning into an applicant without duplicate student records being created. The following flowchart explains how Student CRM looks for a matching record for Passive Applications:

FAQs

Q. What's the difference between a "blank" field and a "null" field?

A. A blank value is a way of saying "I have a value for you, but it is empty". A null value is a way of saying "I have no value for you".

This distinction is important because if the UCAS or MIS IDs are "blank" the system will try and match this to a student. However, if they are "null" the system recognises they were never there, so it knows not to look for anything matching.

Fortunately, the API will stop you from entering blank UCAS or MIS IDs as these are required fields.

Q. I have an occurrence of Active Applications. Will it follow the same rules?

A. No. Active Applications follows a slightly different ruleset, which can be found on the Active Applications - Student Matching article.

Q. These two students didn't match and I think they should have.

A. Please pay attention to the order of matching. Usually when two student records don't match it's because the required fields were provided in a different order to the above.

The system will always err on the side of duplication for Applicants, as it is easier to merge two records than try separating them.

Did this answer your question?