> 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-operator-groups-and-privileges.md). # Operator groups and privileges Configure operator roles, permissions, division scope, and field-level access. An **operator group** aggregates named permissions into an assignable role for Command Centre operators. An operator is someone who logs into Command Centre to do work, such as an administrator, SOC operator, integrator, or installer. Each operator belongs to one or more operator groups. The combined groups decide what actions they can perform, on what item types, in what divisions. This is the access control system for the system itself. It is not about cardholders walking through doors. It is about the operators sitting at consoles. Designing operator groups well is one of the most under-attended parts of a site bringup, and one of the most common sources of "why can't I do this?" support tickets. *** ## What an operator group defines | Element | Purpose | | ----------------------------- | ---------------------------------------------------------------------------------------------------- | | **Verbs** | What actions are permitted (View, Edit, Delete, Approve, Override) | | **Item types** | Cardholders, Access Groups, Doors, Alarm Zones, Reports, Operators, etc. | | **Divisions** | Which divisions the group applies to. Operators inherit privileges down the division tree | | **Field-level authorisation** | Fine-grained: for example, operators may View a cardholder but not see PII fields like medical notes | The **division hierarchy** is the spatial scope. The **verbs x item types** is the functional scope. The **field-level authorisation** is the granular scope inside each item. *** ## Common operator group patterns ### Site Administrator * Verbs: View / Edit / Delete on Cardholders, Access Groups, Visitors * Divisions: their site only (not the whole company) * Field-level: full access including PII ### SOC Operator * Verbs: View / Acknowledge on Alarms, View on Cardholders, Override on Doors (lock/unlock) * Divisions: across all sites they monitor * Field-level: limited PII (need photo and name, not medical or personal data) ### Visitor Receptionist * Verbs: Create / View on Visitors, View on Cardholders * Divisions: lobby / reception only * Field-level: visitor data only ### Channel Partner Installer (during commissioning) * Verbs: Full configuration access. Create / Edit / Delete on Controllers, Doors, Alarm Zones, Schedules * Divisions: the customer site they are commissioning * **Time-boxed.** Privileges are revoked at handover and replaced with maintenance-only access ### Auditor (read-only) * Verbs: View on everything, Reports, Audit Trail * Divisions: company-wide * Field-level: full visibility for compliance review * **Cannot edit anything.** Read-only by construction *** ## The System Operator concept When changes are made by **automated services** rather than humans, such as REST API clients, the workflow engine, or AI Copilot actions, they need to be attributed correctly in the audit trail. Automated actions are attributed to a **System Operator**, or a specific named service operator, rather than a human. This: * Keeps the audit trail honest. This change was machine-driven, not human. * Lets administrators tell "Pete edited this cardholder" from "the HR sync edited this cardholder". * Prevents the API service account from looking like a human operator who never sleeps. **Implication for integrations:** every system-to-system integration should have its own service-account operator group with appropriately scoped privileges. Do not share API credentials between integrations, or you lose audit clarity. *** ## Field-level authorisation Beyond verbs and item types, Command Centre supports **field-level** authorisation. This restricts visibility of specific cardholder fields based on operator group. Sensitive data on a cardholder record might include: * Personal information (medical notes, emergency contacts) * Competencies (which qualifications they hold, sometimes regulated) * Custom fields containing PII or HR data A reception operator who needs to verify a cardholder's identity should see name and photo, but should not see their medical notes. Field-level authorisation enforces this. **Configure** it at the operator group level. Mark specific cardholder fields as visible, editable, or hidden per group. This is one of the things you build right at site bringup if the customer has compliance requirements such as GDPR, HIPAA, or a government data protection regime. *** ## Operator groups for perimeter For a perimeter-equipped site, operator groups should account for: * **Perimeter SOC operator.** Needs full alarm visibility on perimeter zones, but does not need cardholder edit privileges. Acknowledge alarms, override gates if needed, escalate. * **Perimeter installer.** Full configuration on perimeter zones, fence controllers, and sensor calibration. Time-boxed during commissioning. * **Patrol guard.** Limited monitoring, mainly the Guard mobile experience. Acknowledge their assigned alarms only. * **Maintenance technician.** Read-only on configuration, plus the ability to acknowledge maintenance tampers. Should not be able to disable perimeter zones or alter sensor thresholds. A common mistake is giving the maintenance technician the same operator group as the installer. They do not need it, and the privilege creep is a security risk. *** ## Common gotchas * **Privilege creep.** Operators get assigned to "one more group" each time they need a new permission. After a year, an admin has 8 operator groups and effectively unlimited access. Audit operator group membership periodically. * **Division scope wrong.** An operator group applied at the company level instead of the site level gives users access to every site. This is easy to miss in commissioning and painful to fix later. * **Field-level auth missed at bringup.** Adding field-level restrictions later means going back through every operator group. Build them in upfront if compliance demands them. * **Service accounts as humans.** API service accounts that are not clearly named, for example "\[Service: HR Sync]", look like rogue admin accounts in the audit trail. Always name service accounts unambiguously. * **No audit of operator changes.** Operator groups themselves change over time (new group, removed permission). The audit trail of who changed what operator privileges matters as much as cardholder changes. *** 🔗 **Related** * [Command Centre - Cardholders & Credentials](/knowledge-hub/products/cc-software/configure/command-centre-cardholders-and-credentials.md). The identities operators manage. * [Command Centre - Access Groups](/knowledge-hub/products/cc-software/configure/command-centre-access-groups.md). The access control system for cardholders, as distinct from operators. * [Scenario - Monitor operator activity](/knowledge-hub/products/cc-software/configure/configuration-scenarios/scenario-monitor-operator-activity.md). Log an event when an operator views a cardholder record. --- # 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-operator-groups-and-privileges.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.