Public-sector organisation·2023
An inter-agency case management platform
Cases had to move between organisations without losing ownership, evidence, or history. We built one shared system with controlled collaboration.
- Sector
- Public Sector, Case Management
- My role
- Worked across the application and deployment as a full-stack developer within the delivery team.
- Stack
- Laravel, Vue.js, Tailwind, MySQL, REST APIs, queued workers, AWS
In 2023, I was part of the team that built a case management platform for a public-sector organisation. Several participating organisations needed to work on the same cases, but access still had to reflect who owned the case and who had agreed to take part.
A shared case could not mean open access
A case might start with one team and need a response from several others. Its summary, source, evidence, current status, severity, and activity all needed to stay together as it moved between them.
Keeping a separate copy inside each organisation would have protected the boundaries, but it would also have created different versions of the same case. Making every case openly editable would have solved the coordination problem by creating an access problem.
We built around one shared record, with an explicit invitation and acceptance step before another team could join the work.
Making collaboration deliberate
The team that raises a case chooses which organisations to invite. Users in the invited organisation review the request before accepting it, so access is both deliberate and visible in the history.
System administrators have a platform-wide view. Other users work within cases their organisation owns or has accepted. That gives the organisations a shared place to collaborate without removing responsibility for who raised the case and who is expected to respond.
I worked on complete features across the Vue interface, Laravel backend, data model, background jobs, and AWS deployment. The access rules were part of those workflows from the start, not a permissions pass added once the screens were finished.
Escalation without losing the history
Cases could not rely on someone remembering to check them. A scheduled process increases the severity of records that have been idle for too long and notifies the responsible users. The automated change is written to the same activity history as a user action, so collaborators can see when and why the case escalated.
Dashboards, reports, and organisation histories all read from those case records. Supporting documents are stored in S3, while notifications run through queued workers.
What the platform changed
Participating teams can now work from the same case instead of passing copies around. The invitation, acceptance, ownership, escalation, and activity history make it clear who was involved and what happened at each point.
My role covered the application and deployment throughout the build, working across the frontend, backend, and the workflows connecting them.