Staff Files V2 and the Document Workflow Rebuild
December 16 looked like a housekeeping session at first. Brett had cleaned up part of the repo and wanted the task headers and helper structure sanity-checked before the “real” work resumed. But once that review was done, the session widened into something more important: a rethink of what staff files were meant to be, where their truth lived, and how the document workflows should feel in the admin frontend.
The reset behind the feature work
The staff files story here was bigger than a few tabs on page_staff.html. The underlying idea was that staff records needed stronger canonical data, more explicit subsystem boundaries, and document flows that matched the rest of the modern admin surfaces instead of feeling like leftovers from an earlier phase.
That is why the work kept circling around core_source as the canonical store. This was not just UI polish. It was a structural pass on the staff domain itself.
What changed
The staff files upgrade pushed on several fronts at once:
- staff-related subsystems were clarified and expanded,
- document, leave, training, emergency-contact, vehicle, and external-identity flows were treated as part of one broader staff model,
- manual uploads were used as a practical way to diagnose where Monday migration and synchronization still felt unreliable,
- and the document experience started moving toward a desktop-style interaction model instead of a plain list of files.
One of the more revealing details was the hide-versus-delete distinction. That sounds small, but it reflects a more mature approach to records handling: operationally, the team needed a way to pull something out of view without pretending it never existed.
The document workflow got more serious
By the continuation session on December 19, the document side had clearly become its own sub-story. The files were no longer just attachments hanging off a record. They were being reorganised around preview/download/copy actions, better layout, and cleaner service behavior.
This is also where the historical caution matters. The sessions were still diagnosing Monday-related problems and still shaping some of the richer flows. So it would be wrong to present the whole staff files system as fully resolved.
What was true is that the direction had changed:
| Before | After |
|---|---|
| Staff files felt like a scattered collection of tabs and attachments | Staff files were being treated as a coherent subsystem with a stronger backend model |
| Delete was an easy blunt instrument | Hide/soft-removal behavior became part of the design thinking |
| Documents were closer to simple records | Documents were moving toward a fuller file workflow with preview/download/copy behaviors |
| Monday migration issues sat beside the feature as background frustration | Manual upload and diagnostic work became part of understanding how the system should behave |
What to avoid overstating
Two easy mistakes would flatten the history here.
First, Monday migration was not cleanly finished. Second, some of the broader dashboard and sharing ambitions were still ahead of the actual implemented surface. The accurate story is that Brett used these sessions to define the right model and push the system materially closer to it.
Where this led next
The next session stepped away from staff files and back into email operations. But the staff-files work here fed directly into later admin history: better file-serving expectations, stronger staff subsystems, more careful onboarding thinking, and a clearer idea that the admin frontend needed to be the operational source of truth rather than just a viewer for external services.