Somewhere in your access control software there is a line that says the front door unlocks at 7 a.m. It was set during commissioning, probably by an installer who asked what time you open and typed the answer in. It has worked every weekday since, which is exactly the problem.
That line is not a permission. It is not a rule about who may enter. It is an instruction to the controller to release the lock at a fixed moment and hold it released until a second fixed moment, and it will carry that instruction out on a morning when the roads are closed, on a day the office is shut, on the week between Christmas and New Year, and on the morning the one person with a key to the office is off sick and nobody else is coming in. The door does not know any of that. It knows the clock.
A door on an unlock schedule is not an access-controlled door during those hours. It is an open door. That is a fine description of a retail entrance at 10 a.m. and a poor description of most of the doors that end up on unlock schedules.
What auto-unlock actually is
In the four-part model we use for how access control actually works — people, credentials, doors and time — auto-unlock lives entirely in the fourth part, and it is the only one of the four that acts without a person doing anything.
Every other function of the system is reactive. Somebody presents a credential, the controller checks two things, and the lock releases or does not. Auto-unlock inverts that. The controller releases the lock because a time arrived. No credential was presented. No identity was checked. Nothing in the people list or the credential list participated at all.
This matters for two reasons beyond the obvious one. First, an unlocked door produces almost no log. You will have one entry saying the schedule fired, and then nothing about the dozens or hundreds of people who walked through — because nobody presented anything for the system to record. The morning of an incident, the period you most want in the log is precisely the period the log is blank.
Second, the schedule keeps its own counsel. If the door is already unlocked, revoking somebody's access changes nothing about their ability to walk in through it. The former employee whose card you disabled last Friday does not need a card at 7:15 on Monday. This is the quiet failure mode that makes a well-maintained cardholder list less protective than the effort put into it suggests.
The four ways it goes wrong
Nobody arrived. The most common one, and the least dramatic. The opener is delayed, sick, on the wrong site, or stuck behind an accident on the highway. The building opens itself and stands open, unstaffed, until somebody eventually turns up — or until the relock time that evening, if nobody turns up at all.
It is a holiday. Statutory holidays are handled by a separate table that overrides the schedules, and that table is the most commonly broken component in Canadian access control systems. Holiday calendars get populated for the current year during commissioning and are then nobody's job. A table that ran out three years ago treats every statutory day since as an ordinary weekday. Family Day is a Monday, the system says, and Mondays open at seven.
The business is closed that week. Construction shutdowns, a summer closure, a strata office between managers, a tenant who moved out last month and whose suite door is still on the old schedule. None of these appear anywhere the controller can see. The schedule has no concept of "we are not operating this week" — that lives in somebody's head, or in an email.
Snow, flood, fire alarm, power event. Any day the building is meant to stay shut but the decision was made at 5:30 a.m. by a person who has never opened the access control software and would not know which of forty schedules to disable if they had it in front of them.
Every one of those is the same defect wearing four costumes. The schedule asserts something it cannot know — that the building is occupied and operating — and the door acts on the assertion.
First-person-in: the standard answer
The fix has been standard in the trade for decades and is available in essentially every commercial access control platform, usually under one of two names: first-person-in, or supervised unlock.
The mechanism is a single change of logic. The schedule no longer unlocks the door. It arms a window. During that window, the first valid credential presented by somebody in an authorized group triggers the unlock, and the door then stays unlocked for the rest of the scheduled period.
Nobody arrives, the door stays locked. That is the whole of it.
What you get for that one change:
- The building only opens when a person the system recognizes is standing at it. The unlock is no longer a prediction; it is a consequence.
- The unlock is attributable. There is a log entry naming the credential that opened the building, at the exact minute, every single day — which is a far better record than a schedule firing into an empty lobby.
- Holidays, closures and snow days handle themselves without anybody touching the software. On a day nobody comes in, nobody triggers it. The failure mode of a forgotten holiday table becomes "the door stayed locked", which is the direction you want the error to run.
- Staff arriving before the window still get in normally on their own credentials. First-person-in changes when the door opens to the public, not who may enter.
There are only a few decisions to make when configuring it, and they are worth making deliberately rather than accepting the defaults:
Who is in the authorized group? This is not everyone with access to the door. The people permitted to open the building to the public are a smaller list than the people permitted to enter it — a keyholder group, a supervisor group, whoever you would want to be the first person on site. Making it "anyone with access" reproduces most of the original problem with extra steps, because the first cleaner or early-arriving contractor then opens the lobby.
Does the window have a hard end? Most systems let you say the unlock window is armed from 06:30 to 09:30 — meaning if nobody has arrived by 9:30, the door will not auto-unlock at all that day and someone has to do it manually or by an explicit command. Setting that boundary is what keeps a very late arrival from opening a building at 2 p.m. on a day that turned out to be a closure.
What relocks it, and can a person lock it early? The scheduled relock time is the default, and it has the same blind spot in the other direction — it relocks at 18:00 whether or not the building is empty. Make sure whoever closes has a way to lock the door early from a reader or a command, and knows they have it.
None of this is expensive. On most systems it is a configuration change to an existing door and a schedule, with no hardware involved. The reason it is not already in place in most buildings is not cost. It is that the installer configured what was asked for on commissioning day, and nobody has looked at that screen since.
It still depends on your holiday table
First-person-in removes the worst consequence of a stale holiday calendar — the empty building that opens itself — but it does not make the calendar irrelevant, and it is worth being precise about what remains.
Holidays interact with schedules in ways that vary by platform. In many systems a holiday does not simply cancel a schedule; it substitutes a different schedule for that day, and if nobody defined the substitute, the behaviour is whatever the system defaults to. And a first-person-in window armed on a holiday will still open the building if an authorized person comes in to catch up on work — which may be what you want, or may not, but should be a decision rather than a surprise.
The maintenance task is small and annual: open the holiday calendar in January, extend it through the coming year, and check what each of your doors does on those dates. We have written about the holiday schedule nobody updated separately, because it causes trouble well beyond the front door.
One thing the schedule never controls
Worth stating plainly, because the question comes up whenever locking behaviour is discussed: none of this touches getting out.
The BC Building Code requires that locking and fastening devices on a principal entrance door to a building, and on every exit door, include release hardware permitting the door to be readily opened from the inside with not more than one releasing operation and without keys, special devices or specialized knowledge of the door-opening mechanism (BC Building Code 2024, Division B, Sentence 3.4.6.16.(1)). Doors within a floor area — a suite door opening onto a corridor — are governed instead by Article 3.3.1.13, which applies a near-identical test to doors in an access to exit.
A door being locked to the outside at 7 a.m. because nobody arrived is not an egress question. It never was. Egress is a property of the hardware and the code, not of the schedule, and a system whose scheduling changes affect whether people can leave has a hardware problem that predates the schedule. If you are not certain which of your doors depend on the access system to release for egress, that is a conversation to have with whoever is accountable for approving the installation, and it is more urgent than anything else in this article.
The audit question
Here is the whole article compressed into something you can act on this week. Ask whoever administers your access control system for a list, and expect it in writing:
Which of our doors unlock automatically, at what time, on which days, and when do they relock?
Then three follow-ups:
Which of those are on first-person-in, and which are on a plain time schedule? In most buildings the honest answer is that none are on first-person-in, because nobody was ever offered the choice.
What year does our holiday table run out? Not "do we have holidays configured" — the year. There is a specific date in that table beyond which the system has no idea a holiday exists.
Who checked this list last, and when? If the answer is the installer, on commissioning day, then the list describes a building that may have changed tenants, hours and purpose several times since.
The list is usually shorter than people fear and contains at least one entry that surprises somebody — a side door, a stairwell, an interior corridor door put on a schedule for a renovation in a year nobody can name.
The same discipline that keeps access levels auditable applies here, with one difference that makes unlock schedules worth doing first: an over-broad access level still requires somebody to present a credential. An unlock schedule does not require anything of anyone. It is the one setting in your system that opens your building to the entire street, on a timer, and it is usually the setting nobody has read since the day it was typed in.
