What you will learn
- What a roster must respect beyond simply filling shifts
- How rest rules, qualifications and route knowledge constrain rostering
- How sickness and disruption cover is planned
- What crew members see, and how swaps are handled
- Where rostering ends and payroll begins
What this project is
Crew rostering is a constraint problem, not a calendar. Every train needs a driver, and often a guard, who holds the right traction and route qualifications, who has had the required rest since their last duty, and who is not already rostered elsewhere. A system that fills shifts without checking those constraints creates rosters that look complete and cannot legally be worked. The roster must be built around the constraints, with violations shown as errors, not as warnings that can be ignored.
Rosters also have a human side. Crew members need to see their duties, request leave, and swap shifts within the rules. A system that publishes rosters without a fair swap and leave process will be worked around, and the workaround will break the constraint checks. The design should treat the published roster as the record, and every change, swap or cover arrangement as an update to that record with a reason attached.
Core features
- Roster building with rest rules, maximum duty lengths and minimum rest periods enforced as hard constraints
- Qualification tracking for traction, routes and safety competencies, with expiry dates that block rostering when lapsed
- Leave, sickness and availability management, with cover planning for unfilled duties
- Crew self-service for viewing rosters, requesting leave and proposing swaps within the rules
- Disruption cover views that show who is available, rested and qualified at short notice
- Roster publication and change history, so every change has a reason and an author
How it is built
- Model the rules first: rest periods, duty limits, qualifications and route knowledge, agreed with operations and safety teams
- Build the roster editor with constraint checks that run as duties are placed, not only at publication
- Add leave and swap workflows, then the cover planning views used on the day
- Connect to payroll only for the duty data payroll needs, keeping pay rules out of the rostering core
- Run the new roster alongside the old process for one roster period, comparing violations and cover gaps before switching
Technology considerations
Constraint checking is the technical core. Rest rules interact: a duty that looks legal on its own may break a weekly rest rule, and a swap that helps one crew member may break another's rest. The checker should explain each violation in plain language, naming the rule and the duties involved, so a planner can fix it rather than override it. Qualification data must be kept current by the training function, not by planners typing expiry dates from memory.
Rosters are also sensitive personal data. Access should be role-based: crew see their own roster and their swap options, planners see their depot, and managers see the aggregate. Change history matters for fairness disputes, so the system should keep who changed what and when, without turning that history into a surveillance tool.
Challenges to plan for
- Rest-rule violations hidden by manual roster adjustments made outside the system
- Qualifications that lapse mid-roster-period and strand a duty with no qualified cover
- Sickness cover that pulls a crew member off rest and creates a violation the next day
- Swap requests that are fair to one person and unfair to the depot as a whole
Who it is for, and its limits
This suits a railway operator or a depot that rosters its own drivers and guards. It fits operations where rest and qualification rules are strict and where cover matters daily. It does not fit a small heritage line with a handful of volunteers on a fixed rota, and it is not a payroll system: it records duties worked, it does not calculate pay on its own.
A rostering system does not create qualified crew or solve a staffing shortage. It makes the shortage visible earlier and the cover choices safer, but it cannot invent a rested, qualified driver who does not exist. Costs vary with depot count and rule complexity, so confirm with a quote after the rulebook is mapped.
Frequently asked questions
What happens when a qualification expires?
The crew member is blocked from duties that need that qualification until it is renewed. The system flags the expiry in advance so training can be arranged before the roster is affected.
Can crew swap shifts themselves?
They can propose swaps, and the system checks the swap against rest and qualification rules for both people before it is approved. A swap that breaks a rule is refused with the reason shown.
How is sickness cover found?
From crew who are available, rested and qualified for the duty, ranked by how disruptive the cover is to their existing roster. The planner still makes the call; the system narrows the choice.
Does the system handle split shifts?
Yes, where the operating rules allow them. Split shifts are modelled as two duties with a break between them, and rest rules are checked across the whole day, not per duty.
Is the roster linked to pay?
Duties worked can be exported to payroll, but pay calculation stays in payroll. Keeping the two separate avoids turning roster changes into pay disputes.