> 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-automation-engine-and-macros.md).

# Automating activities

Automate Command Centre responses with action plans, logic blocks, and macros.

The **Automation Engine** is Command Centre's deterministic, rule-based automation system. It contains three automation types:

1. **Action Plans**: event-triggered ("when X happens, do Y").
2. **Logic Blocks**: state-evaluated ("if A is true AND B is true, then C").
3. **Macros**: manually invoked or scheduled ("operator clicks Lockdown" or "every night at 23:00").

## The Three Automation Types

### Action Plans (event-triggered)

**Trigger:** something happens in the field (door forced, access denied, fence breach). **Effect:** a sequence of actions runs (raise alarm, notify, log, override).

This is the most common automation type. It is tied to the Monitoring Workspace operator response and is configurable at server, alarm zone, or device level.

### Logic Blocks (state-evaluated)

**Trigger:** a state or combination of states evaluates to true. Logic blocks are essentially Boolean expressions over system state.

**Examples:**

* "If alarm zone is armed AND zone occupancy > 0, raise alert." Catches an arm-while-occupied error.
* "If contractor cardholder AND time outside contractor hours, deny access." An extra layer beyond access groups.
* "If perimeter zone armed AND any gate forced, escalate immediately."

**Use when:** you need conditional logic that pure event triggers cannot express. Logic blocks let you compose state across multiple inputs into a decision.

### Macros (manual or scheduled)

**Trigger:** an operator action ("click Lockdown") or a schedule ("23:00 every night").

**Examples:**

* **Lockdown**: operator-invoked. Locks all external doors, arms all perimeter zones, escalates to the SOC.
* **End-of-day shutdown**: scheduled. Auto-arms after-hours zones, dims reception lighting, locks public doors.
* **Fire alarm response**: operator-invoked. Unlocks designated egress doors, isolates HVAC if integrated, broadcasts to all guards.
* **VIP visit prep**: operator-invoked. Pre-stages access for visitor cards, increases CCTV record quality at relevant readers, alerts the duty manager.

**Use when:** you need a multi-step orchestrated action that does not fit "an event happened" or "a state is true", and you need the operator (or the clock) to kick it off.

## How the three Automation Types differ

| Automation type | Triggered by             | Best for                 | Example                            |
| --------------- | ------------------------ | ------------------------ | ---------------------------------- |
| Action Plan     | An event                 | Reactive alarm response  | Door forced → notify operator      |
| Logic Block     | A state condition        | Conditional rules        | If contractor + after hours → deny |
| Macro           | Manual click or schedule | Multi-step orchestration | Lockdown                           |

{% hint style="info" %}
A common confusion: "I want to lock all doors at 18:00", is that a macro (scheduled) or an action plan (triggered by 18:00 as an event)? Either works in practice, but conceptually it is a macro. There is no "event" that fires at 18:00, just the schedule. Use macros for anything time-based or operator-initiated.
{% endhint %}

## How to think about the three together

A real site uses all three:

* **Action plans** for routine alarm response, the most common and most numerous.
* **Logic blocks** for conditional access rules and complex automation, fewer and more strategic.
* **Macros** for emergency response and end-of-day operations, operator-facing and infrequent but high-impact.

## Common pitfalls

* **Action plan, logic block, or macro?** Choose by trigger model, not by what you want to happen. The action is often the same. What differs is what kicks it off.
* **Logic blocks can become unmaintainable.** A site with 50 interlocking logic blocks where each references three others is a debugging nightmare. Keep logic blocks small and named clearly.
* **Macros need testing.** A "Lockdown" macro that has never been tested is a "we discover it is broken during the actual emergency" waiting to happen. Schedule periodic test invocations.
* **Scheduled macros vs scheduled access.** Do not confuse "macro that runs at 18:00" with "schedule that controls auto-unlock at 18:00." They are different mechanisms even though both involve time. Schedules are for access permission state; macros are for orchestrated actions.

***

🔗 **Related**

* [Scenario - Pulsing an output using Logic Blocks](/knowledge-hub/products/cc-software/configure/configuration-scenarios/scenario-pulsing-an-output-using-logic.md). A worked logic-block recipe.
* [Scenario - Deactivate a Siren after a set time or an Alarm Zone is disarmed](/knowledge-hub/products/cc-software/configure/configuration-scenarios/scenario-deactivate-a-siren-after-a-se.md). A second logic-block recipe.
* [Server - Using a Macro to run an application](/knowledge-hub/products/cc-software/configure/server-configuration/server-using-a-macro-to-run-an-applica.md). Running external applications from a macro.


---

# 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-automation-engine-and-macros.md?ask=<question>&goal=<user_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.