Published at October 26th, 2025 • Last updated 8 days ago

Rules for relationship ID generation during Synchronisation

This article describes the rules for relation ID generation if no ID is available for Student, Staff, and Supervisor relations

 

When synchronising data from customers views, we need unique IDs for each of the different relations that we synchronise. Sometimes these IDs cannot be supplied from the customer. This page describes the strategy we use to generate these IDs given the data. 

Furthermore, we need some algorithm to identify various relations, when they should be linked to each other. These algorithms are also described in this page.

Every ID where a date is used, should be formatted according to the ISO8601 standard without milliseconds, to avoid having whitespaces in the ids.

Staff Organisation Relation

The ID for the Staff Organisation Relation, if the customer cannot supply this is

PersonID_OrganisationID_<Role>_Start date

The <Role> part is one of

  • Employment Type
  • Generic Role Title
  • Post Title

which should be chosen at the beginning of the project.

 

Student Organisation Relation

The id for the Student Organisation Relation is:
PersonID_OrganisationID_StudentType_Start date

 

Student Supervision Relation

The id for the Student Supervision Relation is:
SupervisorStaffId_SupervisorOrganisationId_StudentID_StudentOrganisaitonID_StartDate

Please note that the student supervisor relation is in fact a relation between two relations. E.g. the staff-organisation-relation and the student-organisation-relation. In cases where we have an ID for these two relations, the student supervisor relation is made based on these. When we do not have these IDs we need an algorithm, to uniquely identify student supervisor relation. How this is done is described below.

Information below this, only apply to one Pure installation (York)

When synchronising the Supervisor relation, and no IDs for the various relations are defined, we need a heuristic algorithm to find the StaffOrganisationRelations, and the StudentOrganisationRelation. These are needed in order to correctly say who supervised whom at what time. The algorithm tries to narrow the list of potential student organisation relations, and when the result set contains more than one relation, it proceeds to the next step. Otherwise it uses the matched relation. The same strategy is used in all the algorithms described, noted by "if result > 1"

If an already synchronised StudentSupervisorRelation is removed from the view/data it will be deleted, not retired.

  1. Given the student, find all synchronised student organisation relations.
  2. if result > 1
  3. Remove all organisation relations where the organisation does not match the organisation id from SupervisorRelation
  4. if result > 1
  5. Start date of supervisor relations should be within the start end date range of the StudentOrganisationRelation, if not ignore
  6. if result > 1
  7. End date of supervisor relations should be within the start end date range of the StudentOrganisationRelation, if not ignore
  8. if result > 1
  9. select the first one in the list

 

  1. Given the staff, find all synchronised staff organisation relations.
  2. if result > 1
  3. Remove all organisation relations where the organisation does not match the organisation id from SupervisorRelation
  4. if result > 1
  5. Start date of supervisor relations should be within the start end date range of the StaffOrganisationRelation, if not ignore
  6. if result > 1
  7. End date of supervisor relations should be within the start end date range of the StaffOrganisationRelation, if not ignore
  8. if result > 1
  9. Select only the StaffOrganisationRelation that matches a prioritised list of <Role> from Staff organisation relation specified above
  10. if result > 1
  11. select the first one in the list

 

Student Funding Relation

The ID for the Student Funding Relation is:
StudentId_StudentOrganisationId_AcademicYear_Funder

If an already synchronised StudentFundingRelation is removed from the view/data it will be deleted, not retired.

We need an algorithm to find the correct StudentOrganisationRelation

  1. Given the student, find all synchronised StudentOrganisationRelations
  2. if result > 1
  3. Remove all organisation relations where the organisation does not match the organisation id from SupervisorRelation
  4. if result > 1
  5. select the first one in the list

 

Was this article helpful?

Related articles