Triage findings
Sort findings by severity and entity so you fix what matters first.
By the end you’ll be able to
- Filter and prioritise findings by severity and entity.
- Tell a structural blocker apart from an advisory warning.
- Group findings so they map to a clear day-of-work plan.
An audit can return hundreds of findings. Without triage you'd burn the day on cosmetics while a structural blocker silently fails the submission gate. The Data Quality console exists so you can see the findings grouped, severity-coloured, and entity-filtered before you touch anything.
Findings carry a severity — typically `CRITICAL`, `ERROR`, `WARN`, `INFO`. A `CRITICAL` or `ERROR` against a HESA Data Futures Quality Rule is a structural blocker for the corresponding return: the sign-off pipeline will refuse to mark the return submittable until it clears. A `WARN` is advisory; an `INFO` is a heads-up. Severity is set by the rule, not by you.
Findings also carry an entity (Student, Course, Module, Instance, Entry…) and a rule id. Triaging by entity tends to be the most productive cut — repairing a class of Student findings often clears dozens of rows at once via a single repair recipe.
In this lesson you'll open the Data Quality console for the demo institution, narrow by entity, and look at one structural blocker in detail so you can recognise the shape on a real return.
Walkthrough
- Open Data quality
1.Open the Data Quality console
Browse all findings for the demo institution, grouped by entity and severity.
- Filter by entity
2.Narrow to one entity
Pick Student (or another high-volume entity) so you see only the findings against it.
- Open the audit
3.Read a critical / error finding in full
Open one structural blocker and note: the rule id, the severity, the cited source, and the row identifier — that's everything you need to plan a repair.
Your turn
Open the Data Quality console and filter to a single entity to see the findings against it.
Hint: Use the 'Open Data quality' step above.