Case playbooks overview

While alert playbooks focus on individual alerts, case playbooks let you run automation workflows across the broader scope of an entire case.

Running workflows at the case level provides three primary advantages:

• Case-specific context: You can build automation for operational tasks that apply directly to the case container rather than a specific alert.
• Consolidated execution: You can perform a single action on the case or its combined entities instead of running separate executions for each individual alert, which cuts out redundant work and saves third-party API credits.
• Case-level reaction triggers: You can automatically trigger workflows based on lifecycle changes that happen to the case itself during an investigation.

Understand case playbooks

Because a single case often groups multiple similar alerts together, running playbooks on an alert-by-alert basis can cause inefficiencies. For example, you might see a playbook reset a user's password multiple times, or spend third-party API credits enriching the exact same IP address across ten different alerts.

Case playbooks solve this by looking at the whole case container. You can access all the alerts and entities associated with that case. This lets you run a single operational action for the entire case—such as sending one unified Slack notification to your team or opening a single tracking ticket in an external system—instead of triggering repetitive actions for every individual alert.

Case playbooks also introduce reaction triggers. Instead of only running when an alert first arrives, you can automatically trigger these playbooks based on events that happen during the investigation—like when a case priority changes, or when a case is reassigned.

Common use cases

Case playbooks work best when you need to focus on the overall incident rather than isolated events. Typical scenarios include:

• Upon case creation: Run an automated workflow the moment a new case opens. For example, you can automatically create a tracking ticket in an external IT service management (ITSM) system.
• Manual attachment during an investigation: Run a single, centralized workflow directly on the case container. For example, if you need to rerun an enrichment block on all entities collected from the various alerts, a case playbook runs this action once at the case level instead of looping through each alert separately.
• When using reaction triggers: Automate tasks based on lifecycle updates. For example, you can trigger a Slack notification or assign a new task automatically when the case assignee changes.

Supported triggers

Case playbooks use specific triggers to determine when to run. These are split into two categories:

Ingestion triggers

These triggers control how a playbook attaches when a new case is created:

• All: Attaches the playbook to every newly created case.
• Custom trigger: Attaches the playbook based on specific fields you choose to evaluate.

For more information, see Use triggers in playbooks.

Reaction triggers

These triggers automate responses based on changes made during an active investigation:

• Case assignee change: Triggers when a case is assigned to a different user or role.
• Case priority change: Triggers when a case priority level updates.
• Case stage change: Triggers when a case moves to a new investigation stage.
• Custom case field change: Triggers when a specific custom field or case context value updates.

For more information, see Use reaction triggers in playbooks.

Create and configure case playbooks

To set up a case playbook, use the following steps:

Choose the playbook scope

When you create a new playbook, select Case from the scope options (the default option is Alert).

When you choose Case, the playbook builder updates to show the ingestion and reaction triggers designed for case-level operations.

Execute actions

All standard actions in the Content Hub work natively over cases.

Entity scoping and deduplication

A case functions as a higher-level container that groups multiple individual alerts together. Because each alert within that case brings its own separate list of entities, the exact same entity (such as a specific IP address or hostname) often appears across multiple alerts. When you look at a case as a whole, it naturally contains these duplicate entities.

To manage this, a case playbook automatically aggregates all entities from the different alerts associated with the case into a single list. To keep your third-party API use efficient and prevent you from processing the same entity multiple times, every case playbook action includes a Deduplicate entities toggle:

• Enabled (Default): The action finds unique entities (by identifier and type) and sends only that unique set to your third-party tools. When the results come back, the playbook automatically copies those details to all matching duplicate entities across the case, which helps you save API credits.

• Disabled: Turn this off if you need to run an action against every single instance of an entity (including duplicates), or if you want to keep duplicates in your initial scope so you can filter them later in the workflow.

Deduplication inside loops

When you use an entities loop, a Deduplicate loop entities toggle is available inside the Start Loop step settings (enabled by default):

• Enabled (Default): The loop runs only on distinct case entities and skips duplicates. When this setting is active, the behavior of actions inside the loop depends on the Lock scope to iteration setting:
  • Lock scope to iteration is enabled: Internal loop actions only see the current looped entity. When the action finishes, the results automatically apply to all matching duplicates across the case.
  • Lock scope to iteration is disabled: Internal loop actions remain aware of the entire case entity array, allowing you to manually configure how the step handles the broader context just like any standard action.
• Disabled: The loop iterates over every duplicate entity across all alerts in the case. This is useful when a specific instance of a duplicate entity contains unique alert-level properties that you need to process.

Work with playbook blocks

Playbook blocks are scope-agnostic, meaning they are not tied to a specific alert or case context. You can build a block once and use it in both alert and case playbooks.

When you place a block inside a case playbook, the block step includes a Deduplicate entities toggle that is turned on by default. When active, When active, all internal block actions run against unique case entities, skip duplicates, and automatically apply the results to matching duplicates across the case.

Limitations and considerations

Playbook names must be unique across the platform. A case playbook and an alert playbook cannot share the exact same name. For details on attachment limits and playbook capacity, see Attach playbooks to an alert or case.

Integration versioning for full case playbook support

To ensure stable functionality with case playbooks, update your integrations to minimum required versions. If you're using an older version of these integrations, some case playbook features may not work as expected.

Refer to the specific integration's documentation for detailed feature support and update instructions.

Need more help? Get answers from Community members and Google SecOps professionals.