School system integration: a practical guide

Define the purpose of the connection

Start with the work the integration should remove or improve. For example, the payment service may need an accurate list of active pupils and their authorised payers. It probably does not need every field held by the MIS. A useful specification identifies the minimum records required for a named task.

Write the purpose in a sentence that office staff can understand. Then list the data items needed to achieve it. This creates a basis for technical testing and a practical discussion with the school's data-protection lead. Avoid treating an available export as permission to share every field it contains.

Decide which system owns each field

A source of truth is the system where an authorised correction should be made. Different fields can have different sources, but each needs a clear rule. If two systems both change the same value, define how conflicts are resolved and whether staff must approve an update.

Data item	Decision to document
Pupil identity	The stable identifier used to match records
Contact details	Where corrections are verified and entered
Adult-pupil relationship	How access decisions and restrictions are represented
Class or group	When a move becomes effective downstream
Leaver status	What stops immediately and what remains for approved purposes
Payment balance	Which financial system controls the figure and its history

Do not use a name alone as a reliable identifier. Names change, spellings vary and different pupils can share the same name. Ask how duplicates are detected and who resolves them.

Specify direction, timing and deletion

State whether each flow is one-way or two-way. Define the expected delay between an approved source change and its appearance elsewhere. A nightly synchronisation may be adequate for some planning data but unsuitable for a restriction that needs prompt action. Agree a separate urgent process where necessary.

Deletion needs particular care. A pupil leaving the school should not automatically erase records that must be retained, but continued access to an active parent service may need to stop. Distinguish access removal, deactivation, archival and deletion. Ask what happens if a source record disappears because of an error: the connection should not silently turn a temporary problem into widespread data loss.

Examine the technical and contractual boundary

Request a clear diagram showing all parties involved, including any intermediary connection service. Record which organisation can see each field, where credentials are held and who is responsible for reporting an incident. Confirm whether setup, transaction volumes or additional modules create separate charges.

Use supported interfaces and suitably restricted accounts. A connection should not depend on a technician's personal login or an administrator credential shared in email. Agree how secrets are stored, rotated and revoked, and how the school can stop a connection if a supplier changes or an incident occurs.

Make failure visible

An integration can stop completely, update only some records or continue running with incorrect mappings. The school needs evidence of successful processing and a way to see exceptions. Define who receives an alert, who checks it and how quickly the issue should be investigated.

Useful operational information includes the last successful run, record counts, rejected items and a plain explanation of the problem. Avoid alerts containing unnecessary pupil data. For more detailed investigation, authorised staff should use an appropriate secure view rather than circulate full exports by email.

Plan safe retries. If the same message or batch arrives twice, it should not create duplicate charges, contacts or bookings. Ask the supplier to demonstrate how it identifies repeated work and handles a partially completed transfer. The practical requirement is that recovery does not introduce a second error.

Test the awkward cases

Use fictional records to test a new pupil, a renamed pupil, a shared surname, a changed contact relationship, a class move, a leaver and a record temporarily missing from an export. Include an unavailable destination and a correction made after a failed transfer.

For each scenario, write down the expected result in both systems. Check permissions as well as data values. A technically successful synchronisation that gives the wrong adult access is not a successful integration. Have the relevant office or safeguarding process owner review those tests alongside the technical team.

Give the connection an operating owner

Maintain a register of integrations, their purpose, supplier contacts, credentials owner, review date and stop procedure. Recheck them when either system changes, a contract renews or the school's process changes. Retire unused connections explicitly.

Good integration reduces duplicate work while making exceptions easier to manage. It should leave staff knowing where to make a correction, how to confirm that it arrived and who can help if it did not. For a major system change, combine this work with the school data migration plan.