How Access Decisions Work

This page explains the model behind every unlock: who is allowed through a door, in what order the checks run, and how facility-wide settings, Access Scopes, and per-door overrides interact. Read this first — every other page builds on these concepts.

The two ways a user can be allowed

A user can be allowed through a door via either of two independent paths. Passing one path is enough.

Grants are additive to rules: a user is allowed if either a rule matches or a grant matches. Both paths honour their respective operating hours.

Example: your facility rule says Members with status Current can unlock. A cleaner who isn't a member can still be let in by giving them a per-user grant to the "Service entries" scope — no rule change needed.

The full decision sequence

When a user taps Unlock in the mobile app, the server checks the following, in order. The first failed check denies the unlock and records the reason in the Access Logs.

1. Is the user's access enabled? The Access enabled switch on the user's row in User Access is an admin kill switch. When off, the user cannot unlock any door regardless of rules or grants. (Denial reason: access_disabled)
2. Is the door blocked or in maintenance? A door set to Block all access at this door denies every user unlock. Maintenance mode Force closed holds the relay locked and ignores unlock attempts; Force open holds the door open. (An admin's Unlock door button in Performance Hub still works even during Force closed.)
3. Rule path OR grant path.
   • Rule path: take the effective rules for this door (see hierarchy below). The user passes if the current time is inside the rules' operating hours (empty hours = always allowed) and either a person-type rule matches (their person type equals the rule's type, and their membership status is in the rule's status list — an empty status list means any status) or one of their tags (synced tags and custom tags both count) is in the allowed-tags list.
   • Grant path: the user passes if they have Facility-wide access, a grant for this specific door, or a grant for any Access Scope that contains this door — and, if the grant has its own operating hours set, the current time is within them.
   • If neither path passes → denied (no_matching_rule_or_grant)
4. Geofence check (if enabled). Using the location the phone reports:
   • If the phone could not provide a location → denied (location_unavailable)
   • If the GPS reading is less accurate than the Require GPS accuracy better than setting → denied (gps_too_imprecise)
   • If the user's distance from the geofence centre exceeds radius + GPS accuracy + accuracy buffer → denied (outside_geofence)
   • The server is authoritative — a spoofed location on the phone is still rejected server-side.
5. Is the door controller online? If the controller hasn't reported in (heartbeat within the last 5 minutes), the unlock cannot be delivered (device_offline). If the command is sent but the controller doesn't confirm, the event is recorded as Timed out.
6. Unlock. The relay releases for the door's Hold time (1–30 seconds, default 10), then automatically re-locks. The event is recorded as Confirmed unlocked once the controller confirms.

The policy hierarchy: facility → scope → door

Access rules and the geofence each follow a three-level override hierarchy. The most specific level wins:

Facility defaults            (Settings → Access Rules / Geofencing)
   ↑ overridden by
Access Scope override        (Settings → Access Scopes → scope → Rules / Geofence tab)
   ↑ overridden by
Per-door override            (Doors → door → Access rules / Geofence tab)

• Per-door overrides win over Access Scope overrides, which in turn win over facility defaults.
• A door with no override simply inherits ("Inherits facility" in the UI).
• Overrides replace the corresponding settings wholesale for that door/scope — they are not merged field-by-field with the facility values you see on screen.
• A door can be in multiple scopes. Scopes are independent of the physical location label set when pairing the device — that label is only used to organise the Doors list.
• The hierarchy applies to the rule path only. Per-user grants are evaluated separately and are not changed by scope or door rule overrides (though a "Block all access" door setting and the geofence still apply to everyone).
• App lock (device re-authentication) is facility-level only — it cannot be overridden per scope or per door.

What OTP sign-in does and doesn't do

Signing in to the mobile app (one-time code via SMS or email) is authentication only — it proves who the user is. It does not grant door access by itself. Every unlock is authorised individually using the decision sequence above. A user can be signed in to the app and still see "You don't have access to this door."

Glossary

Related pages

• Access Rules — configuring the facility-wide rule set
• Access Scopes — door bundles and scope-level overrides
• Geofencing — location checks
• User Access — per-user grants and the kill switch
• Reference — every denial reason and default in one table