Enterprise Ops Platforms

A Self-Hosted Workforce Administration Platform With Middleware-Enforced, Admin-First Access Control

How Pfactorial Technologies built an admin-first workforce platform that replaces spreadsheet-and-email administration with centrally enforced access control and automated leave policy.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_Worklog_Platform image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client ran the day-to-day mechanics of running an organisation - work logs, leave, work-from-home requests, project assignment, holidays, performance scores, service expenses, and an employee loan programme - through spreadsheets and email threads, with no single system of record and no enforced separation between what an employee could see and what only an administrator should.

A simple internal tool bolted onto the spreadsheets would not have solved this: the data spans everything from timesheets to salary-adjacent expense and loan figures that can't be protected by hiding a button in the interface, leave policy differs by employment type and has to stay correct without manual tracking, and whatever shipped had to hold up under daily production use, not a demo.

Pfactorial built the Worklog Platform: a Django and React system with role-based access control enforced once, centrally, in request middleware - and a separate automation layer that credits leave and flags compliance problems on a daily schedule without an administrator touching a spreadsheet.

Why this engagement is representative This engagement demonstrates Pfactorial's ability to treat access control as infrastructure - one declarative permission map enforced centrally - rather than a policy that has to be reimplemented correctly in every view of a system carrying salary-adjacent data.

THE CHALLENGE

Replacing spreadsheets and email with a single system meant solving problems that don't show up until the data includes salary-adjacent records and inconsistent HR policy.

1. Workforce data spans everything from timesheets to salary-adjacent records

Worklogs, leave, WFH requests, project assignment, performance scores, service expenses, and an employee loan programme all need one home, but not all of it can be employee-visible.

2. Leave policy differs by employment type and has to stay correct without manual tracking

Probation, Permanent, Contract, and Intern staff each follow a different credit schedule - milestone-based, quarterly, or cycle-based - and tracking that by hand drifts out of sync almost immediately.

3. Hiding a button in the UI isn't access control

Expense and loan data has to be genuinely inaccessible to employee accounts, not just missing from a menu - if the API doesn't independently enforce it, the data leaks the first time someone calls the endpoint directly.

4. Historical work logs need to stay a record of what happened, not what someone edited later

But legitimate corrections do arise, so the system needs an audited exception path rather than either an open door or a permanent lock.

The real brief Not "build an admin panel over the spreadsheets" but "make admin-only data unreachable by construction, and make leave policy something the system gets right automatically, not something an administrator has to remember."

THE SOLUTION

Pfactorial built the Worklog Platform around three cooperating components - a Django REST API, a React admin console, and a standalone automation layer - with role-based access control enforced once, centrally, before any view code runs.

Pfactorial_Case_Study_Worklog_Platform image 2

Figure 1 - Every request passes through one enforced access-control layer before it reaches business logic; automation runs independently of the request cycle entirely.

Architectural principles

Access control enforced once, centrally - AccessRestrictionMiddleware checks endpoint and method against a declarative permission map before any view executes, so a new endpoint is admin-only by default until explicitly opened - the safe failure mode for data as sensitive as expenses and loans.
Automation as a separate layer, not a cron job bolted onto the API - The Backbone scripts operate directly on the database with SQLAlchemy and pandas, independent of the request/response cycle, so leave crediting and compliance alerting run on schedule with no dependency on anyone being logged in.
Policy encoded as data, not scattered as logic - Employment type drives leave crediting automatically - milestone, quarterly, and cycle-based credits - so a policy change doesn't require re-implementing checks across every module that touches leave.
Exceptions are audited, not just allowed - The 14-day worklog edit window and the log-access-request queue give employees a real path to correct old entries without leaving the system able to silently rewrite history.

CAPABILITIES DELIVERED

Each capability replaces a spreadsheet-or-email process with one that enforces its own policy and its own access rules.

CAPABILITY	WHAT IT DOES
Employee & account management	Admin-only account creation, four employment types that drive leave policy automatically, and per-employee suspension of logging access.
Worklog oversight & timesheets	Consolidated worklog view and exportable timesheet, with a 14-day edit window and an audited log-access-request exception queue.
Leave management	Pending-to-approved workflow, automated type-aware crediting, and a special-leave endpoint for ad-hoc credits outside standard policy.
Work-from-home administration	The same request/approval pattern as leave, with WFH balances tracked separately from leave balances.
Project & assignment management	Hierarchical projects and sub-projects, employee-proposed project requests, and a restore endpoint for recovering deleted projects.
Expense analytics dashboard	Admin-only ingestion of the service-expense spreadsheet rendered as interactive dashboards - the API refuses non-admin tokens outright.

Pfactorial_Case_Study_Worklog_Platform image 3

Figure 2 - The same access model and the same policy engine cover every module, from timesheets to loan records.

Design note The permission map is declarative and bidirectional - it also defines the employee-only actions an admin account cannot perform, such as applying for leave on someone else's behalf. One auditable map that a new endpoint inherits by default, not a check an engineer has to remember to add, is the actual deliverable.

ENGINEERING FOR SCALE AND RELIABILITY

Six decisions kept the platform simple enough for a single in-house team to operate.

JWT authentication with a Redis-backed blacklist, not server-side sessions

Stateless JWT calls suit the single-page frontend; the Redis blacklist restores the server-side logout control that pure stateless JWT would otherwise lose.

A declarative middleware permission map instead of per-view permission classes

One auditable map covers every endpoint, so no individual view can forget a permission check the way per-view framework classes allow.

Cron-driven automation instead of a task queue

Two daily jobs don't justify a message broker and a worker fleet; cron keeps failures visible in one log instead of spread across queue infrastructure.

Component-level React state instead of a global store

Admin screens are independent modules, not a tightly coupled app, so a global state library would have added indirection without a corresponding benefit.

One ASGI process instead of separate REST and WebSocket services

Daphne serves both REST traffic and the Channels notification layer from a single process, simplifying process supervision on a self-hosted deployment.

Process-level supervision instead of manual restarts

PM2 supervises the backend and frontend independently and restarts either on failure, while GitHub Actions ships a push to main automatically - the entire footprint stays operable by one in-house team.

DELIVERY APPROACH

The engagement built outward from the access-control layer, so every module that came after inherited the same enforcement.

1. Architecture & component split - establishing the three-tier split - Django API, React SPA, standalone Backbone automation - behind a single nginx reverse proxy.

2. Access-control layer - building AccessRestrictionMiddleware and the declarative permission map before any admin module went live, so every later endpoint inherited admin-only-by-default protection.

3. Core administration modules - employee and account management, worklog oversight and timesheets, leave management, work-from-home administration, and project and assignment management.

4. Automation layer - leave crediting and daily log-compliance alerting, run on cron directly against the database with SQLAlchemy and pandas.

5. Real-time layer - in-app notifications over Django Channels and Redis-backed WebSockets, so approvals and announcements reach employees the moment an administrator acts.

6. Deployment & CI/CD - PM2 process supervision and GitHub Actions continuous deployment on a single self-hosted server.

RESULTS AND IMPACT

Pfactorial_Case_Study_Worklog_Platform image 4

- Key outcomes from this engagement.

The platform is built, deployed, and running in daily production use, giving administrators one system of record for work logs, leave, WFH, projects, holidays, announcements, performance, expenses, and employee loans in place of spreadsheets and email threads.

Because access control is enforced centrally in middleware rather than per view, and leave crediting and compliance alerting run automatically on a daily schedule, the administrator's role has shifted from bookkeeping and manual checks toward reviewing exceptions and approving requests.

What it enabled commercially

The client now runs its entire workforce administration - including salary-adjacent expense and loan data - on infrastructure a single in-house IT team can operate on one server, with a stateless JWT design that leaves room to scale out without a redesign.

WHY PFACTORIAL

This engagement reflects Pfactorial's ability to design access control as infrastructure rather than an afterthought - a declarative permission model enforced centrally, automation that runs independently of the request cycle, and a self-hosted deployment sized to what an in-house team can actually operate.

Pfactorial_Case_Study_Worklog_Platform image 5

- Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with organisations that need internal operations - HR, finance-adjacent data, compliance-sensitive workflows - turned into systems with real, enforced access control. If you're evaluating an internal-tooling or workforce-administration platform, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_Worklog_Platform image 6

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies built an admin-first workforce platform that replaces spreadsheet-and-email administration with centrally enforced access control and automated leave policy.