> 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-groups.md). # Access groups Learn how access groups control cardholder access to doors and zones. An **access group** is the rule that says "these doors and zones, during these hours, for cardholders in this group." It is the primary mechanism for granting cardholders permission to access specific doors and areas. A cardholder with no access group cannot get through any door. A cardholder with the right access group walks in during the hours that group permits. The core formula is: **cardholder + access group + schedule = access at reader.** *** ## What an access group defines | Element | Purpose | | ------------------------ | --------------------------------------------------------------------------------- | | **Doors / access zones** | Which physical access points this group covers | | **Schedule** | Time periods during which access is permitted (for example "Mon-Fri 06:00-18:00") | | **Day Categories** | Special-day handling (holidays, weekends, weekdays) | | **Division** | Tenancy. Which division owns this access group | A cardholder is added to the access group, and the system grants them access at the listed doors and zones during the schedule's permitted hours, respecting day categories. *** ## How access groups compose Multiple access groups combine **additively** for a cardholder: ``` Cardholder: Pete ├── Access Group: Office Staff (Mon-Fri 06:00-18:00, all office doors) ├── Access Group: Server Room Approved (Mon-Fri 09:00-17:00, server room only) └── Access Group: After-Hours Emergency (24/7, main entrance only) Result: - Pete can enter office doors Mon-Fri 06:00-18:00 - Pete can enter server room Mon-Fri 09:00-17:00 (subset of office hours) - Pete can enter main entrance 24/7 (overrides time limits for that one door) ``` This is why access design tends toward many small access groups rather than a few large ones. You compose them. *** ## Schedules and day categories **Schedules** define repeating time windows. Typical patterns: * "Office Hours": Mon-Fri 06:00-18:00 * "24/7": always * "Cleaner Hours": Mon-Sat 17:00-22:00 * "Weekend Only" **Day categories** classify days. Typical: * Default 1 category, fine for 24/7 sites * Weekdays / Weekends * Weekdays / Saturday / Sunday (granular weekend) * Plus per-site overrides for public holidays Day categories must be configured **before** schedules (schedules reference day categories). Schedules must be configured **before** access groups (access groups reference schedules). *** ## Best practices **Naming.** Use descriptive names. "Office Staff Mon-Fri 06-18" is better than "Group A". **Cap at 10 per cardholder.** Gallagher guidance is a maximum of about 10 access groups per cardholder. More than that hurts performance and makes audit hard. If a cardholder needs more, redesign the groups. **One purpose per group.** A group should answer one access need ("server room approved"), not bundle multiple ("VIP staff all areas"). Compose by adding more groups, not by stuffing one group. **Use divisions for tenancy.** Multi-tenant sites should split access groups by division, so each tenant's groups are isolated. **Anti-passback considerations.** If anti-passback is enabled, a cardholder who badges into a zone cannot badge into the same zone again until they badge out. This affects access group design. *** ## Common mistakes * **Forgetting the schedule.** A door added to an access group with no schedule means no access. The schedule is not optional. * **Day category drift.** Holidays added to the calendar but day categories not updated, so people get unexpected access on public holidays. * **Mass-edit gone wrong.** Bulk-changing an access group affects every cardholder in it. Always verify scope before applying. * **Over-broad groups.** "All staff all doors" sounds simple but breaks audit, mustering, and least-privilege principles. *** ## How this fits in the install flow Access groups are created **after** divisions, day categories, schedules, controllers, alarm zones, access zones, doors, readers, inputs, and outputs are all in place. They are the policy layer that grants cardholders permission to use the physical layer that is already configured. *** 🔗 **Related** * [Command Centre - Cardholders & Credentials](/knowledge-hub/products/cc-software/configure/command-centre-cardholders-and-credentials.md). The identities that access groups are assigned to. * [Command Centre - Bulk Operations](/knowledge-hub/products/cc-software/operate/command-centre-bulk-operations.md). Adding or changing access groups across many cardholders at once. * [Command Centre - Operator Groups & Privileges](/knowledge-hub/products/cc-software/configure/command-centre-operator-groups-and-privileges.md). The access control system for operators, as distinct from cardholders. --- # 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-groups.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.