Approval workflow portal with a trail an inspector can read
A controlled-access portal where every software, instrument, and equipment access request is approved through a defined workflow and permanently recorded in an audit trail.
- Web application
- Role-based portal
- raised
- line manager
- 3quality
- 4IT
the chain is configurable; the record is not
- Structured request intake
- Multi-stage approvals
- Append-only audit trail
What we were solving
In regulated pharmaceutical manufacturing, every system a person can log into and every instrument they can operate has to be access-controlled — and that control has to be provable months or years later.
Access requests handled over email and paper produce no reliable record. When an auditor asks who approved a particular analyst's access to a particular instrument, and on what date, a mail thread is not an answer.
The organisation needed request handling, approval, and evidence to live in one system, with roles that mirror how IT and quality functions actually divide responsibility.
How we built it
- 01
Model the request, not the form
We started from the object being requested — software, an instrument, an equipment ID, a department transfer — because each has different approvers and different retention expectations. A single generic form would have collapsed those distinctions and lost the very detail an audit depends on.
- 02
Make the workflow configurable
Approval chains change as departments reorganise. Rather than hard-coding routes, we built Workflow Settings and Form Dropdowns so IT administrators can adjust approvers and request fields without a release — while the audit trail keeps recording against the rules in force at the time.
- 03
Treat the audit trail as the primary artifact
The audit trail is append-only and captures actor, action, target, and timestamp for every state change. It is not a log we added at the end; the request lifecycle was designed around producing it.
- 04
Separate the requester view from the admin view
Requesters see their own access, their open requests, and what is pending on them. IT Super Admins get the master data — Software Master, Instruments, Equipment IDs, Departments — plus analytics across the whole request population. Same system, two very different surfaces.
What the platform does
Structured request intake
Distinct request types for software, instruments, and equipment access, each with its own fields and approver chain.
Multi-stage approvals
Requests route through configurable approval stages with a clear pending-on-you queue for every reviewer.
Append-only audit trail
Every state change records actor, action, target, and timestamp — retained and queryable for inspection.
Access register
Each user can see exactly what they currently hold access to, so reviews and revocations start from fact.
Master data management
Software Master, Instruments, Equipment IDs, and Departments are managed centrally rather than typed free-hand.
Analytics and reporting
Volume, ageing, and outcome breakdowns across the request population, exportable for review meetings.
What it runs on, and where it landed
- Frontend
- Next.jsReactTypeScriptTailwind CSS
- Backend
- NestJSNode.jsREST APIs
- Data
- PostgreSQLPrisma
- Platform
- Role-based access controlAudit logging
- Access requests, approvals, and evidence live in a single system instead of scattered mail threads
- Approval routes are reconfigurable by administrators without a code release
- Every request carries a complete, queryable history from submission to closure
- Requesters can self-serve their current access rather than asking IT
Common questions
01Can this portal support 21 CFR Part 11 or GxP requirements?
The system was built around the controls those frameworks care about — unique user identity, role-based authorisation, defined approval workflows, and an append-only audit trail with actor and timestamp on every action. Formal compliance always depends on your own validation, SOPs, and qualification activities, which we support but do not certify on your behalf.
02Can approval workflows be changed after go-live?
Yes. Approval stages, approvers, and request form fields are configuration rather than code, so IT administrators can adapt them as departments reorganise. Historical records remain tied to the rules that applied when they were raised.
03Can it integrate with our existing identity provider?
Yes. The authentication layer is designed to sit behind an enterprise identity provider via SSO, so access follows joiners, movers, and leavers handled in your directory.
More of our work
Service contracts visible before they lapse
A command centre for a franchise service network — service complaints, AMC renewals, customer devices, and branch-level cash and revenue in one operational view.
Read case studyMulti-vertical booking operatorSix inventory types behind one search
A full online travel agency covering hotels, flights, properties, cars, tours, and cruises — with a companion Android app for booking and trip management on the move.
Read case studyMulti-campus institution groupOne picture across every campus
A multi-campus school administration platform covering admissions, academics, fees, daily operations, and communication — with AI-generated summaries over campus activity.
Read case studyTell us what you are building.
Share the problem and we will come back with an approach, a rough shape of the work, and what it would take to deliver it.