Web application

Clinic scheduling application

SchedulingRole-based accessApproval workflow

A custom scheduling system that lets administrators build and revise schedules while guaranteeing that staff only ever see approved ones.

The director's approval screen: a per-day coverage summary, a green line confirming no conflicts, and a form for adding a shift block before approving. — The director's approval screen — coverage counted per day, conflicts checked, and the option to edit before posting.

The clinic, its brand and every member of staff shown here are fabricated, to protect the real client.

Overview

A scheduling application for a rehabilitation clinic, built by Vahzor and in weekly use. Administrators build and revise the week; technicians and therapists see only what a director has approved.

The problem

A clinic week is assembled from recurring availability, approved time off and two treatment locations, and it changes after it is published. The risk is not building the schedule — it is a member of staff working from a draft that was never approved, or from a version that has since been revised.

Six kinds of staff need six different amounts of authority over the same data, and hiding a button is not access control.

The solution

Schedules move through an explicit chain: draft, submitted for approval, posted. Editing a posted week does not change what staff see; it opens a revision that a director has to approve, and until then everyone keeps reading a frozen copy of the live schedule.

Availability, time off and partial-day absences feed a conflict check that runs continuously against the 30-minute grid, so a scheduler is told about a clash while building rather than after posting.

Every role's permissions are enforced in Postgres with row-level security. The interface reflects what the database will allow rather than being the thing that decides.

Screens

The weekly schedule builder: a 30-minute grid of technician assignments for the week, above it a banner explaining that changes need director approval, and a panel listing six detected conflicts across three technicians. — The build view, with conflict detection running — three technicians, three approved absences, checked against the grid below.

The technician's view of the posted week: one row per technician, days across, each cell a shift with its location, under a line reading 'Final, Director-approved schedules only'. — What staff see — final, director-approved schedules only. This is the view the approval chain exists to protect.

A list of weekly schedules, each labelled with its state: posted, revision pending, submitted for approval, or draft. — Every week and where it sits in the approval chain — draft, submitted, posted, and a posted week with a revision waiting.

The availability overview: a grid of who is available, unavailable or on time off each day, above a pending time-off request and a warning that no technicians are available during part of Friday. — Availability and time off in one grid, with coverage gaps called out before the week is built. The Friday cell is a partial-day absence, stored to the half hour.

The technician's weekly schedule on a phone: one technician per row, days across, with colour-coded Land and Pool assignments. — The technician view on a phone — a read-only copy of the approved week.

The real interface, running on a fabricated dataset. It opens on the director's approval queue; the button in the corner switches between five staff roles. Edits work and reset on reload.

Technical notes

Row-level security policies are the authorization model — the client holds no privileged path.
Scheduling is stored on a 30-minute grid, which is what lets partial-day time off be compared against assignments exactly rather than approximately.

Have a similar project?

Describe what you are trying to build or improve, and Vahzor will help define a practical path to it.

Discuss a Project What Vahzor builds

Different problem, different solution: JJ Rabbit Creative