Secure multi-role staff and client portal (live staff prototype)

Problem

An organisation ran reporting, project activity, company knowledge and internal forms across spreadsheets, email threads and separate tools. Leadership had no single live view of client health, and clients had no self-service view of their own results.

Goal

One application with single sign-in, a staff side and a later client side, on cloud infrastructure the company already used and at a small monthly running cost, with sensitive data protected by the structure of the system rather than by convention.

My role

Architect and team lead for a small team (design, web development, and me on the AI and data layer, the timeline and the security model). I wrote the scope and architecture specification, the approval deck and presenter notes, commissioned and reviewed the legal and regulatory research, and had the specification cross-reviewed twice by independent AI models. I then built and deployed the staff-side prototype and the blog-writing tool inside it, in the stack the team's web developer had chosen, so the web developer can take it over.

Solution

A web API with a separate single-page front end, a managed relational database and serverless hosting. Everything is designed around server-side authorisation and hard isolation between clients, staff and sensitive HR data.

The staff side runs as a working prototype. It owns little data on purpose: it reads the company's existing client records system through a read-only database login, and asks an existing assistant service for leave rules, balances, requests and answers from company knowledge, so no rule or client fact exists twice. Its own tables hold users and roles, announcements, weekly reports, a change log and the blog-writing tool's work.

A blog-writing tool inside the portal turns one client's month of keywords into a long post and a set of short posts, with a plan the writer approves first and automatic checks on every post.

Still a design: the client side, the separate HR permission and sensitive HR data, layered client isolation, a credential vault protected by cloud key management, the append-only audit log, and a nightly copy from the existing reporting warehouse. None of these is presented as built.

How it works

Sign-in. Staff sign in with their company account through a sign-in proxy in front of the app, with no portal password. Built: the server verifies the signed identity assertion on every request (signature, issuer, audience and company domain), and the person must also be on the portal's own user list, which an hourly sync keeps in step with the staff list, so people who leave lose access. Design: matching on the provider's stable account id, and in-app credentials for clients.

Roles. Built: three staff roles (employee, leadership, admin), checked on the server, with automated tests that an employee cannot reach leadership or admin actions. Design: a client role, plus a separately granted HR permission that administrators cannot grant themselves.

Five rules for every screen. Authorise on the server for every request; remove sensitive columns in the query itself; deny by default; log every read and export of sensitive records (who, which record, which kind of field, never the value); and prove with automated tests that an employee cannot reach HR data and a client cannot reach another client's data or staff data. The prototype checks every request on the server and keeps sensitive fields out of staff lists; the HR and client tests wait for the parts they protect.

Staff pages (built). A home page per role: leadership sees clients needing attention, leave waiting for a decision with approve and decline, who is out, and announcements. Staff see client pages, request leave and check balances, file a weekly report, and use a directory with an org chart, a report centre that links to the existing reporting, a knowledge library and an admin page. A chat button on every page asks the assistant service.

Blog-writing tool (built). For one client and month the writer enters keywords and, optionally, a topic, a location and pages to link. The tool checks the season, weather and local news for that place and month, proposes titles, keyword placement and links, and writes only after the writer approves the plan. The long post is written in two halves and each short post separately, one AI call per request, so every step fits the hosting time limit. Each post is then checked for word count, long dashes, links outside the approved list, links between the long and short posts in both directions, questions or endings repeated across the set, filler phrases, and facts left marked for a person to confirm. Client facts are read from the client records system on every call and never copied in, contact details never go to the model, and a monthly usage cap stops spending. Access is limited to the content and search teams and leadership, enforced on the server.

Layered client isolation (design). Every client request is scoped from the session, never from an id the browser supplies. The sensitive HR data sits in a separate database area reachable only by credentials the client-facing code does not hold. The client side runs as its own deployment with its own identity, and row-level filtering constrains queries even if application code is wrong. Backups and database administration count as HR data access.

Audit. Built: a change log records role and access changes, announcements, leave decisions, blog sets created or deleted, and people the hourly sync removes, and admins see the latest entries. Design: an append-only audit log, enforced by database permissions and mirrored to the cloud provider's logging, records refusals as well as successful access.

Reporting (design). Reporting pages read only the application database, fed nightly from the warehouse. Project activity is pulled per project, because the project tool's account-wide feed leaves out completed work.

Portability (design). Names, paths and storage are configuration, so a second deployment is not a rewrite.

Technical challenges

Client isolation that survives a bug in application code.

Separating "runs the system" from "sees everyone's HR records".

Deciding, after legal and regulatory research, which sensitive HR fields to hold at all: the necessary ones held encrypted with every reveal logged, and the most sensitive identifiers kept out entirely.

An audit log that resists someone who has database access.

A reporting source that cannot push changes, so the design has to pull.

Keeping the audit log out of the knowledge assistant's reach, and the assistant scoped by role.

Keeping the running cost well under budget.

Building the prototype on systems that already ran, reading their data and asking their services instead of copying either, so no rule or fact lives in two places.

Fitting long-form AI writing inside a hosting request time limit by splitting the work into steps the page runs one at a time.

Capabilities

Staff single sign-on
Server-side role checks for three staff roles
Leadership home with leave decisions
Leave requests and balances
Staff-facing client pages with provisional health labels
Staff directory and org chart
Weekly team reports
Report centre
Knowledge library and chat assistant
Blog-writing tool with automatic checks and a monthly usage cap
Admin console with a change log
Client logins (design)
Separate HR permission (design)
Credential vault (design)
Immutable access log (design)

Technology

Impact

A working staff-side prototype is live behind company sign-in, with automated tests for its access rules, and the blog-writing tool inside it is open to the content writer. The rest remains a written architecture and approval deck, corrected through two independent review rounds, with regulatory questions researched before any sensitive table exists. No usage outcomes are claimed.

Skills demonstrated

Security architecture and threat modelling
Multi-tenant isolation
Privacy by design for HR data
Identity integration
Full-stack web development
AI writing workflow design
Data pipeline design
Cost planning
Team leadership
Executive communication