Denied at certain times or certain doors

Likely causes

• Access level, group or partition changed: the failing reader isn't in the holder's level any more

  ~25%

  Log shows access denied with the cardholder correctly identified by name. The card read perfectly; the decision said no. Stop looking at the wire.

• Schedule or time-zone boundary

  ~22%

  Denials cluster at a clock time rather than at a door. Read the schedule attached to the access level and the one attached to the reader: they are usually different objects, and one of them ends when the calls start.

• Credential expired, deactivated, or on a temporary or visitor profile

  ~18%

  Log names the holder and gives a reason: expired, inactive, void. Check activation and deactivation dates and any use-count limit on the record.

• Holiday table active

  ~12%

  Denials across the whole site on one date, then normal again. A holiday overrides every schedule that references it, and it is usually attached to more schedules than anyone remembers.

• Panel time drift, time zone, or DST mismatch between panel and server

  ~10%

  Events land in the log at the wrong clock time, or the door unlocks and relocks an hour off. Compare panel time to server time to real time, and check which one is the source and what zone each thinks it is in.

• First-person-in / unlock-on-first-credential not arming

  ~8%

  Door stays locked through the whole business day and somebody props it. The feature needs a valid read from a member of the right group inside the schedule window. Check which group is authorised and whether anyone in it actually badged.

• Antipassback, occupancy or two-person rule denying a legitimate read

  ~5%

  The denial reason names the rule. The system is working exactly as configured; the policy is wrong for how the door is really used.

What to bring

• Laptop or phone with head-end client
• Test credential you can enroll and delete
• Screenshots of the log: the timestamps are the evidence
• Site access-level and schedule documentation
• The owner's written authority to change anything

Steps

1. 1

   Step 1: Read the denial reason in the log, word for word

   The reason string is the answer most of the time: denied by access level, expired, unknown, out of schedule, antipassback. And a read that reached the panel at all clears the reader, the cable and the card format off your list.

   If that doesn’t do it

   No event at all? The read never got there. Go to Card works at one door, not another or Reader dead: no light, no beep.

2. 2

   Step 2: Ask two questions before you open anything: what time does it fail, and at which doors

   A time pattern points at schedules, holidays or clock drift. A door pattern points at the access level or the reader's assignment. A one-person pattern points at that credential record. Thirty seconds of asking beats an hour at the panel.

   If that doesn’t do it

   No pattern at all: pull a week of history for that holder and read it.

3. 3

   Step 3: Diff the failing cardholder against a working one

   Open both records side by side: status, activation and expiry dates, access levels, partition or site. Diffing two records finds what reading one never will.

   If that doesn’t do it

   Records look identical: follow the access level to the reader.

4. 4

   Step 4: Follow the access level all the way to the reader and the schedule

   An access level is a list of readers crossed with a schedule. Confirm the failing reader is in the list and the schedule actually covers the time it fails. Watch for a shared schedule object that got edited for somebody else's benefit.

   If that doesn’t do it

   Level and schedule are right: check panel time.

5. 5

   Step 5: Check panel time against server time and against real time

   Include time zone, DST setting and whether the panel takes its time from the server. Drift and a DST mismatch will break a perfect schedule for an hour, or for half the year.

   If that doesn’t do it

   Re-sync the panel and re-test at the failing time of day.

6. 6

   Step 6: Check the holiday table and what references it

   A holiday nobody remembers entering will shut a schedule down for a whole day, site-wide. Verify which schedules the holiday group is really attached to, not which ones you assume.

   If that doesn’t do it

   Correct the holiday or detach it from the schedule, with the owner's say-so.

7. 7

   Step 7: Prove it with a purpose-made test credential, then delete it

   Enroll a test card carrying only the access level in question. Badge at the failing door inside the window and outside it. That proves the decision layer end to end, costs nothing, and removes all argument. Then delete it, and confirm it is gone.

   If that doesn’t do it

   Test card behaves correctly but the holder's doesn't: the fault is in that holder's record, not the configuration.

More Access Control guides

• Reader dead: no light, no beep
• Valid read, door never unlocks
• Card works at one door, not another
• Nuisance door held and forced alarms
• Intermittent reads and ghost reads on Wiegand
• Read range short at one reader
• Keypad won't take the PIN

All 54 guides