The problem
The rules guards follow are not fixed. A gate closes for maintenance, a site tightens its screening, a new contractor category needs different questions. Each of those is a small change, and each one was a request that had to be built.
That put a developer in the middle of ordinary operational decisions. Supervisors knew exactly what needed to change and had no way to change it, so the queue grew and the rules on the ground drifted from the rules in the system.
The questionnaires were the sharpest version of the problem, because they change most often and matter most when something goes wrong.
The solution
Move configuration out of code and into data. If the gates, protocols, and questions are records rather than hardcoded screens, the people who own those decisions can edit them directly.
Model-Driven App for administration
The right choice here precisely because this is structured data with a lot of relationships and no need for a bespoke layout. Forms and views come from the model, so a new field is a schema change rather than a redesign.
Questions managed per gate
Administrators add and remove questions against a specific gate, because a service entrance and a visitor entrance do not need the same screening. Changing what guards ask is editing a record, and it takes effect without a release.
Dataverse relationships
Protocols attach to gates, questions attach to questionnaires. The model enforces that a gate cannot reference a protocol that does not exist, a constraint a spreadsheet cannot express.
Security roles
Who may change a protocol is enforced at the data layer, not by hiding a button. Supervisors configure; guards do not.
The result
Operational changes stopped being development requests. A supervisor who decides a gate needs different screening makes that change themselves, the same day.
Because the configuration is the system of record, the rules the system holds and the rules actually in force stay the same thing.
The structure carries forward: adding a gate or a protocol is a data entry task, so growth does not require rebuilding.
What supervisors configure here is what guards are asked on shift, through the companion app covered in the visitor entry case study.
Outcomes here are described in kind rather than in numbers. I don’t have permission to publish this client’s measurements, and inventing figures to fill the gap would make the rest of this page worth less.
Last updated