Where Academy concepts appear in your MIS

Whatever student record system your college runs, the same concepts exist: a learner, an aim, dates, a funding model, monitoring codes and an outcome.

What differs is where they live on screen, and that varies by product, by version and by how your college has configured it.

That is why this Academy gives system-neutral steps as the default. They are true regardless of the software, and they describe what has to be true rather than which menu to click.

Supplier-specific guidance appears only where it has been verified against that supplier's documentation for a stated version. We do not publish a screen path we cannot verify, because a confidently wrong instruction is worse than no instruction.

Build your own internal mapping: for each concept in this Academy, where does it live in your system, who maintains it, and what report shows it.

That mapping is the most useful induction document an MIS team can have, and it is specific to your configuration in a way no external guide can be.

A single table, built once, saves every new starter weeks.

• The concept, in Academy terms.
• Where it lives in your system.
• Who owns it operationally.
• Which report shows it.
• What commonly goes wrong with it here.

Keep it against your system version, and review it after an upgrade. Menu locations move, and a map that silently goes out of date is worse than none.

Where you have verified supplier documentation for a step, record the reference. That is what makes the step defensible if somebody follows it and something goes wrong.

The Academy's diagnostic records carry a system-neutral block by default and a supplier block only where a verified source has been recorded, which is the same discipline applied externally.

Two things change what your system does: an upgrade from the supplier, and a configuration change made by your own college.

Both can change what appears in the return, and neither announces itself in the data.

The pattern to watch for is a sudden change in validation volume or funded record count that coincides with a system change rather than with anything that happened to learners. When a large number of records start behaving differently at once, the cause is almost never the learners.

The defence is a test generation and validation after any upgrade, before it reaches a live return. It takes an hour and it converts a potential crisis into a known issue.

The funding year rollover is the biggest configuration event of the year. Programme templates, funding models, monitoring codes and aim references all need review before the first enrolments, not before the first return, because an enrolment created under last year's configuration carries the error from day one.

Keep a record of what changed and when. When something behaves unexpectedly three months later, the change log is the fastest route to the cause.

Run a test extract through validation under the new specification before the first live generation of a funding year, and after any supplier upgrade. Compare record counts and validation profile against the previous known-good run.

Maintain a dated configuration change log alongside the system map, covering template changes, code list changes and upgrades, so a behavioural change can be matched to a cause rather than investigated from scratch.