> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-access-zones.md). # Access zones Configure physical access zones for anti-passback, mustering, and occupancy tracking. An **access zone** is a physical area within a site that cardholders move between via controlled doors. When a cardholder badges through a door, they transition from one zone to another. Zones enable three high-value capabilities: 1. **Anti-passback (APB)**: prevents tailgating by enforcing "you must exit before re-entering." 2. **Mustering / roll call**: knowing who is in which zone during an emergency evacuation. 3. **Zone counts**: how many cardholders are currently in each zone (occupancy management). {% hint style="info" %} Access zones are physical and spatial. Do not confuse them with [Alarm Zones](/knowledge-hub/products/cc-software/configure/alarm-zones.md), which group items for event management. They serve different purposes and are configured separately. {% endhint %} ## How zones work Doors define transitions between access zones. A door has an entry side and an exit side, each connected to an access zone: ``` [Outside Zone] --Reader Out--> [Lobby Zone] --Reader Out--> [Office Floor Zone] <--Reader In-- <--Reader In-- ``` When Pete badges at the lobby door from outside: * His current zone changes from "Outside" to "Lobby". * The system records the transition and timestamp. * The Lobby zone count increments. When Pete badges into the Office Floor: * Lobby count decrements, Office Floor count increments. * Pete's zone is now "Office Floor". ## Anti-passback (APB) **The problem APB solves:** tailgating. A cardholder badges in, then holds the door for a buddy who did not badge. **How APB enforces:** if APB is enabled, the system rejects a re-entry attempt to a zone the cardholder is already in. They have to badge out first. **Modes:** * **Hard APB**: re-entry rejected outright. * **Soft APB**: re-entry permitted but logged as a violation (useful for non-critical sites). * **Timed APB**: re-entry rejected only if attempted within N minutes. **Limitations:** * APB requires both readers at the door (entry and exit). * A door with only an entry reader cannot do APB cleanly. * APB enforcement breaks if a cardholder leaves via an unmanned door (for example an emergency exit). ## Mustering / roll call In an emergency (evacuation, drill, lockdown), the operator needs to know who is where. Access zones enable this: * Each cardholder's current zone is tracked. * The operator pulls a "who is in zone X" report. * This is compared against expected presence to identify people unaccounted for. For perimeter sites, zone tracking includes outdoor zones (carparks, perimeter approach areas), which is useful for site-wide mustering. **Caveats:** * Mustering is only as good as the badging discipline. People who tailgate or leave without badging are "still in" their last known zone. * Manual zone overrides (an operator changes a cardholder's zone) help correct discipline gaps. ## Zone counts The current occupancy of each zone, displayed on: * Command Centre Client (zone count tile) * Site Plans (visual occupancy on a floor plan) * Reports (historical occupancy patterns) **Use cases:** * Capacity management (do not exceed N people in a zone) * Distancing thresholds * Visitor escort verification (X visitors in an escort area) * Perimeter monitoring (how many vehicles in a carpark) ## Zones and alarm states A cardholder's access can depend on the alarm state of the zone they are entering: * An access zone can be assigned an [alarm zone](/knowledge-hub/products/cc-software/configure/alarm-zones.md). * When the alarm zone is armed, cardholders without "disarm" privilege are denied. * When disarmed, normal access rules apply. This is the bridge between access control and intruder alarms. A cardholder in an access group with the "Change to Disarmed state" privilege can disarm the zone by badging, granting them access and turning off the alarm in one action. ## Configuration ordering Access zones depend on schedules being configured first. The order is: 1. Divisions 2. Day Categories 3. Schedules (access zone schedules live here) 4. Controllers 5. Alarm Zones 6. **Access Zones** 7. Doors (assign each door's entry and exit access zones) 8. Readers 9. Inputs 10. Outputs 11. Access Groups (reference access zones) 12. Cardholders ## Common mistakes * **Forgetting to assign access zones to a door.** The door works for access but the system cannot track zone transitions, breaking APB and mustering. * **APB enforcement on a door without two readers.** APB requires entry and exit readers. Single-reader doors cannot enforce cleanly. * **Mismatched zone topology.** If two doors define inconsistent zone transitions (Door A says "Lobby to Office", Door B says "Outside to Office") cardholders get into illogical states. * **Site plans not updated.** Zone counts only display correctly if site plan zone shapes are drawn. This is easy to skip during commissioning. *** 🔗 **Related** * [Command Centre - Access Groups](/knowledge-hub/products/cc-software/configure/command-centre-access-groups.md). The policy layer that grants access to zones and doors. * [Command Centre - Alarm Zones](/knowledge-hub/products/cc-software/configure/alarm-zones.md). Event management zones, distinct from access zones. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-access-zones.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.