Applications · Client work / Case study
AUSA: case access that follows the role
A confidential staff management system for the AUSA law firm, where tiered permissions decide which cases each role is able to open.
Contribution
Firm management system, staff roles, and tiered case-access permissions
Tiered access
Role-based case permissions
Confidential project / permission-tier illustration
Project context
Client work for the AUSA law firm, sharing its origins with the related IRLI engagement. The application is under NDA and is internal to the firm: there is no public address for a visitor to open, so this case study carries no project link. The overview below describes the delivered system at a high level without exposing case records, internal screens, source code, or deployment details.
Confidential application under NDA. This project has no public link because the system is internal to the firm and has no visitor-facing website. The diagram is a purpose-made abstraction, not a screenshot or a depiction of the real interface.
From sign-in to permitted case access
- 01A staff member signs in
- 02Their role sets their permissions
- 03Only permitted cases open
- 04Case work happens in one system
01
The brief: one system for the firm, not one view for everyone
The staff of a law firm do not all work on the same cases, and the people who share a case do not all need the same view of it. AUSA needed a management system for its people and its case work: a single place to do the job, where what each person could reach was part of the design rather than something arranged afterward. McKay built that system, including the staff roles and the tiers of case access attached to them.
02
The access problem: a permission is a decision, not a filter
Leaving a case off a screen and refusing to serve it are different things, and only the second is worth relying on. A management system holding case information earns trust when the check sits with the request, so a case a role may not open stays closed however it is asked for. Designing toward least privilege, where a role is given the access its work requires and no more, is what makes tiers meaningful rather than cosmetic.
03
The tiers: permissions attached to the role, not the person
Attaching access to a role rather than to an individual is what keeps a system like this maintainable. Staff join, change duties, and move on; when each person's reach is assembled by hand, the arrangement drifts out of date quietly and nobody can say what it currently is. Roles make the levels explicit and reviewable, so changing what a tier may see is one decision instead of a sweep through every account. That role-based pattern is long established in general practice; the specific tiers, data model, and internal interfaces of this system are not disclosed here.
04
The design consideration: confidentiality is a professional duty first
In a legal setting, who may see a case file is not simply a product preference. Rules of professional conduct place a duty of confidentiality on the firm, and software holding case information sits inside that duty rather than alongside it. That framing is why the access tiers were treated as a requirement to state plainly and honor in the application, instead of a convenience setting. This is a design consideration, not a claim that the software discharges the firm's professional obligations or that it was audited against them.
05
The result: a firm system, described within its limits
The delivered work was a management system for AUSA's staff and case work with tiered permissions built into it. Its portfolio value is that combination: a real application for a real firm, where access control belonged to the brief rather than arriving late. Because the engagement is confidential, this case study uses an abstract illustration and reports no screens, figures, or operational results. It shares its origins with the IRLI project, which covers the case-data consolidation and retrieval side of that work.
Delivered outcomes
- A management system for firm staff, organized around the cases they work on.
- Staff roles carrying distinct, tiered levels of access to case information.
- Case access defined by role within the application, rather than arranged per person by hand.
Connected projects
Have a similar problem to solve?
Discuss your project