Imports and integrations: CSV import for learner support software first

Providers already hold learner and course data somewhere: a management information system, a student record system, an apprenticeship platform. Nobody wants to type it again. This page explains how Inclusion Studio plans to handle data coming in and out. This is planned work. Nothing here is available yet.

Why does learner support software need a CSV import?

Without a way to bring learners in, a support tool starts as an empty box, and staff copy details from another screen. Copying creates errors, and errors in a support record matter. The wrong course or the wrong tutor means the wrong person sees a sensitive plan.

At the same time, integrations are easy to oversell. Many products claim to “integrate with everything”. In practice each connection has limits on what can be read, whether anything can be written back, how often data refreshes and who maintains it.

What is the plan, step by step?

1. CSV import and export first. A provider uploads a file of learners, courses, tutors and enrolments. The product shows how columns map, flags problems and lets a person confirm before anything is saved.
2. Reconciliation. Each import records what was added, changed or skipped, so a person can check it against the source.
3. Repeatable and safe. The same file imported twice should not create duplicates. Errors are listed row by row and do not silently drop data.
4. CSV export. Provider-approved exports return support information in a structured file for the provider’s own use. See evidence export.
5. One connector, chosen from real pilot demand. After the pilot starts, we will ask providers which system matters most and build one connector for it, not a long list.
6. Per connection controls. Each connection will have granted scopes, an owner on the provider side, a mapping, health status, error handling and a way to revoke it.

Why one connector and not many?

Because each real integration needs maintenance, testing with a real provider and agreement on what data may move. It is better to do one well. We will not infer that a system accepts write-back because it has a read-only data interface. Any connector will state exactly what it can and cannot do.

What data would an import need?

As little as possible. Typically: a learner identifier, name, course or programme, start date, tutor or assessor, and for apprentices the employer. Support information, such as health details, should not be imported from other systems unless a provider has assessed the need and lawful basis. The Individualised Learner Record has its own specification for funding returns, which is separate from this. See the ILR glossary entry.

Who sees what?

Imports and connectors are administrative functions:

Imported records are subject to the same permissions as any other. See also subprocessors for how supporting services will be documented.

What is in the prototype today, and what is being built?

In the prototype: nothing. Five fictional learners are written into the page. There is no import, no export and no connection to any system.

Planned for the pilot:

• CSV import with mapping, validation, reconciliation and clear errors.
• CSV export for provider-approved outputs.

Planned after the pilot slice: one connector chosen from real pilot demand. It will not be described as available until it has passed testing against a real sandbox, including reconciliation, and its read and write scope is published.

Later or not planned: a catalogue of connectors, two-way synchronisation by default, and integrations with safeguarding or occupational health systems. Those specialist boundaries are preserved. See safeguarding boundaries.

The status of this page is “planned”: it is on the roadmap and has not started. See the roadmap.

Who is this for?

IT and systems staff who need to know what will connect and how. Inclusion leads who want to avoid double entry. Data protection officers who want to review each flow. See IT and systems.

What does this look like in practice? (fictional example)

A fictional apprenticeship provider starts its pilot by exporting a learner list from its student record system as a CSV file. The inclusion lead uploads it, maps the columns for learner identifier, name, programme, start date, tutor and employer, and sees a preview with two rows flagged for missing tutors. She fixes those in the file and uploads again. The import report shows what was added, changed and skipped. Importing the same file the next week updates existing learners and does not duplicate them. No connector is involved, and the provider can decide later whether one is worth requesting. This is a fictional example.

Related guides and next steps

• Choosing learner support software
• DPIA for learner support software
• Tell us which system matters most on the pilot page.