The failure is routing, not detection
Most projects concentrate on which signals predict risk. They fail when the alert reaches a dashboard nobody opens or an advisor with no capacity.
The pattern that predicts withdrawal is visible in hindsight in almost every case. The question is whether anybody saw it while there was still time.
Institutions know a great deal about their students. Attendance, engagement, financial holds, early assessment performance — all captured, all in separate systems.
This paper argues that early alert programmes fail on routing and ownership rather than on modelling, examines the ethical question that predictive analytics about students raises, and sets out what a data foundation has to provide for an advisor to trust a flag enough to act on it.
If you read nothing else, read these. The analysis that follows sets out the evidence for each.
Most projects concentrate on which signals predict risk. They fail when the alert reaches a dashboard nobody opens or an advisor with no capacity.
An advisor who questions why a student was flagged needs an answer traceable to source, not asserted by a model nobody can inspect.
Without it, the programme accumulates flags and no knowledge about which responses work.
Predicting who will fail carries real risk of becoming self-fulfilling, and the institution should decide its position rather than inherit one.
Four components are needed and the last two are usually missing.
Signals combined into one view rather than three systems. A named owner for every alert. An intervention record capturing what was tried and what happened. And effectiveness reporting so the institution learns which interventions actually change outcomes.
Programmes that build the first two and not the last two produce a dashboard, a sense of activity, and no institutional learning. After two cycles the programme is questioned, and there is no evidence with which to defend it.
Unifying student data across the student information system, the learning platform, finance and engagement tools is the unglamorous majority of the work.
The advantage of doing it properly on a governed platform is not speed. It is that when an advisor questions why a student was flagged, the answer is traceable back to source rather than asserted by a model nobody can inspect. An advisor who cannot interrogate a flag will stop acting on flags, and the programme quietly dies.
Access design is the other prerequisite. Legitimate educational interest has to be enforced through security roles rather than asserted in a policy document, and it should be designed before the first dashboard rather than retrofitted after a registrar raises it.
Predicting which students will struggle is useful and it carries a risk that deserves to be named: a flag can become self-fulfilling if it changes how staff treat a student.
Institutions should decide their position deliberately. What is the flag used for, who can see it, is the student told, and how is the institution checking that being flagged does not disadvantage anybody.
We raise this in every education engagement of this kind, not because it prevents the work but because a position taken deliberately is defensible and one inherited by default is not.
Every paper in this series ends with a framework you can run internally. We would rather you used it and reached your own conclusion than took ours on trust.
Five stages. The last two are what most programmes omit.
Combine academic, financial and engagement data on a governed foundation with lineage.
Enforce legitimate educational interest by role before the first dashboard is published.
Every alert to a named advisor with the capacity to act, not to a dashboard.
The intervention and its outcome, so the institution accumulates knowledge.
Effectiveness by intervention type, measured across a full academic cycle.
The same argument lands differently across an executive team. These are the three versions worth separating.
Microsoft's own documentation for the product behaviour described above. We would rather you verified the basis than accepted our summary of it.
On these references: each entry names a Microsoft Learn article or documentation area by title, because deep links change while titles are stable. Searching the title on learn.microsoft.com will reach the current version. Where we have cited a figure or a product behaviour, it is Microsoft's statement rather than ours; where we have given a number of our own it is labelled as such in the text.
We will map your current signal sources and show what a combined advisor view would look like, including how the access model would satisfy your registrar.
Institutions typically have less endpoint coverage than they believe, concentrated in devices owned by departments rather than by central IT.
The students who disappear between deposit and registration had already chosen you. Something in the following weeks made the decision reversible again.
Describe the situation in your own words.