A request arrives for everything held on a student who enrolled six years ago, moved between two schools in the district, and whose paperwork spans a paper era and a scanned one.
The short answer
A records request is a completeness question, and completeness is decided by the structure long before the request arrives. Filing by student, then record category, then year means the answer is a folder rather than a search — and it means a transfer between schools moves a coherent file rather than a scattering. A workflow uses the Read Details from File step to identify the student and record type on each document and the Move step to keep that structure current as things arrive, which is what makes it complete years later.
Steps this uses
Before and after
As they arrive
After the workflow
Six years of one student's record, in categories, dated by what is on each document rather than when it was scanned.
Setting it up
This is the sentence. Send it to the builder and the steps below appear on a canvas, wired and named, for you to change before anything runs.
When a student document arrives by email or upload, read the student and the record category off it, rename it date-first, and file it under that student, then the category, then the school year.
Categories rather than one undifferentiated file, because a request is often for part of a record rather than all of it, and categories are also how access is restricted.
Which record types your district separates is a policy question. Whatever the answer, the rule should route them to their own restricted location rather than a subfolder, since a subfolder normally inherits the access of the folder above it.
Not the date it was scanned. A form completed in 2021 and digitised in 2026 belongs in 2021, and getting this wrong makes a chronological record unreadable.
A student moving between schools should arrive as a complete file. That is only possible if the file was complete where they came from, which is an argument for maintaining the structure continuously rather than assembling it on request.
When a request arrives, the record is whatever it already is. Nothing can be done at that point except search harder. This is why the filing structure matters more than the request process: the work that makes a request answerable in minutes happened over the six years preceding it, one document at a time, and it either happened or it did not.
Digitising a paper file produces a batch of documents that all arrived today and describe events across years. Filing by scan date collapses a student's history into one moment and destroys the chronology, which is most of what a cumulative record is for. The date has to come off the document.
It organizes and finds. It does not decide what may be released, redact anything, log a disclosure, or track a request through to fulfilment. Those are the records office's judgement and process, governed by rules this does not attempt to interpret. What it removes is the search.
FAQ
By student, then record category, then year, with each document named by the date on it. Categories matter because requests are often for part of a record and because access is usually restricted by category rather than by student.
The date on the document, not the date it was scanned. A whole paper file digitised in one afternoon would otherwise appear to have happened on that afternoon, which destroys the chronology that makes a cumulative record useful.
No. It finds what is held for a student. What may be disclosed, to whom, with what redaction and what logging, is the records office's judgement under rules that a document system should not attempt to interpret on its behalf.
A student moving between schools should arrive as a complete, legible file rather than a scattering. That is only possible if the record was already complete where they left, which is the argument for maintaining the structure continuously rather than assembling it when asked.
Because nothing can be added to a record once somebody is asking for it.
5 GB free · No credit card required