> 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/operate/command-centre-bulk-operations.md). # Bulk Operations Choose Bulk Changes, CSV configuration, or the REST API for large-scale Command Centre updates. #### What are the three ways to mass-change data in Command Centre, and when to use each one? There are three paths for mass-changing data in Command Centre, each suited to a different scenario: 1. **Bulk Changes feature (in-product).** Cardholder Viewer mass operations. Best for ad-hoc admin tasks (mass-disable, mass-add-access-group, purge inactive). 2. **CSV-based Bulk Configuration.** Upload a CSV to create or update cardholders, doors, and schedules en masse. Best for site bringup, migrations from another access control system, and periodic batch updates. 3. **REST API.** Programmatic. Best for ongoing integrations (HR system joiner/mover/leaver, automated provisioning). {% hint style="warning" %} For a customer with thousands of cardholders, **never** do this manually. Pick the right bulk path for the situation. {% endhint %} *** ## Bulk Changes (in-product, Cardholder Viewer) An admin-facing feature for mass-changing cardholder records based on filter criteria. It is built into the Cardholder Viewer in Command Centre Client and Command Centre Web. **Typical workflow:** 1. Filter cardholders by criteria (division, access group, expiry, custom field). 2. Define the change: add access group, remove access group, change card state, update field, or purge. 3. Preview the affected cardholders. 4. Apply the change. **Common use cases:** | Use case | Pattern | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------- | | New office opens, add 50 staff to "Auckland Office" access group | Filter: cardholders in division Auckland; Change: add access group | | Contract ends, disable all cardholders flagged as "Contractor X" | Filter: custom field Contractor=X; Change: set state Disabled | | Annual purge of dormant cards | Filter: no card activity in 12 months; Change: bulk purge inactive | | Schedule change, update access group times for night-shift staff | Filter: cardholders in "Night Shift" access group; Change: replace access group | **Bulk change definitions can be saved and re-run.** This is useful for repeating operations (quarterly cleanup, periodic audit-driven changes). **Inactive cardholder purge** is a specialised variant. It finds cardholders with no recent activity and purges them, with the audit trail preserved. *** ## CSV-based Bulk Configuration Upload a CSV file containing cardholder data (or door/schedule data) and Command Centre creates or updates the corresponding records. **Typical workflow:** 1. Export current data as CSV (or build a CSV from another source such as an HR export or a prior access control system migration). 2. Make changes in the spreadsheet. 3. Re-upload the CSV. 4. Command Centre matches records (by ID, name, or custom key), creates new ones, and updates changed ones. **Common use cases:** | Use case | Pattern | | ---------------------------------------------------------------------------------------- | -------------------------------- | | Site bringup, bulk-creating 5,000 cardholders from an HR export | New CSV upload | | Migration from another access control system, mapping old cards to Gallagher cardholders | Mapped CSV with old card numbers | | Periodic HR sync (manual), quarterly export from HRIS reconciled with Command Centre | Reconciliation CSV | | Test data load, populate a demo or training site | Test CSV | **Data Maps** describe how CSV columns map to Command Centre fields. This is important for getting the upload right, because a misnamed column silently misses fields. **Caveats:** * CSV does not handle complex relationships (biometric enrolments, photo uploads). Those are separate workflows. * Bulk uploads can take time on large sites. Do not run during peak operational hours. * Always test on a small sample CSV before running the full upload. *** ## REST API (programmatic) **When to use the API instead of CSV or Bulk Changes:** * **Ongoing automation.** An HR system fires events on joiner/mover/leaver. API integration provisions, updates, and disables in real time. * **External system integration.** A visitor management system creates temporary cardholders via API. * **Multi-system orchestration.** An identity governance system manages access groups across Command Centre and other systems via API. The API is the right answer when the cardholder lifecycle is **driven by another system**, not by an admin sitting at the Command Centre Client. **Concurrency note.** The API uses optimistic concurrency control. If two integrators try to update the same cardholder at once, the second gets HTTP 409 Conflict and must refetch and retry. Bulk Changes and CSV Configuration handle this internally; the API exposes it to the integrator. See [Representational State Transfer (REST) API](/knowledge-hub/products/cc-software/configure/interface-options/api/representational-state-transfer-rest-api.md). *** #### How to choose the right bulk change method? | Scenario | Use | | ------------------------------------------------------------------- | ------------------------------------------------------- | | Ad-hoc admin task ("disable all contractors from Vendor X") | Bulk Changes | | Site bringup, load thousands of cardholders from an existing system | CSV Bulk Configuration | | One-time migration from another access control system | CSV Bulk Configuration | | Ongoing HR-driven cardholder lifecycle | REST API | | Integration with a visitor management system | REST API | | Quarterly reconciliation between HR and Command Centre | CSV Bulk Configuration (manual) or REST API (automated) | | Annual cleanup of dormant cardholders | Bulk Changes (Inactive Purge) | *** #### What to watch out for when making bulk changes? * **Doing it manually.** A site with 1,000 cardholders should not be edited one at a time. If an admin is opening cardholder records in a loop, they are missing a bulk path. * **Not previewing.** Bulk Changes shows a preview of affected records. Always check before applying. Mass-disabling 5,000 cardholders by mistake is recoverable but embarrassing. * **CSV column names.** Upload fails or silently skips records when columns do not match the data map. Always test small first. * **Concurrency on the API.** Integrators that do not handle 409 Conflict end up with corrupted cardholder state. * **No audit context.** API-driven changes attribute to the API service operator, not the human who triggered them upstream. Use distinct API service accounts per integration to maintain attribution clarity. *** 🔗 **Related** * [Command Centre - Cardholders & Credentials](/knowledge-hub/products/cc-software/configure/command-centre-cardholders-and-credentials.md). The single-cardholder flow these operations scale up. * [Command Centre - Access Groups](/knowledge-hub/products/cc-software/configure/command-centre-access-groups.md). The most common thing bulk operations add or change. * [Command Centre - Move Cardholder Utility](https://github.com/GGLSecDev/gitbook-spaces/tree/main/tech-support/installs-and-downloads/tools-and-utilities/command-centre-move-cardholder-utility.md). A separate downloadable utility, not the in-product bulk-change feature. --- # 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/operate/command-centre-bulk-operations.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.