Use reaction triggers in playbooks
A reaction trigger acts as a post-ingestion trigger configured during the initial playbook setup. Standard triggers execute immediately upon ingestion. In contrast, reaction triggers automate playbooks based on real-time modifications or specific events that occur during an active investigation.
By introducing event-based logic, reaction triggers eliminate the need for analysts to manually attach playbooks when an alert state changes.
Use cases
The following examples demonstrate how to use reaction triggers to automate common investigative workflows:
Automate enrichment for newly discovered entities
- Goal: Ensure all entities associated with an investigation are automatically enriched, even if they are added after initial alert ingestion.
- Scenario: An analyst manually attaches a suspicious IP address to an active investigation.
- Outcome: The Entity Added reaction trigger detects the new entity and automatically executes an enrichment playbook, providing immediate reputation data.
Dynamic incident escalation and notification
- Goal: Automatically notify senior stakeholders when the severity of an investigation increases.
- Scenario: A Tier 1 analyst escalates an alert priority from Medium to Critical.
- Outcome: The Alert Priority Changed trigger executes a workflow that sends an automated email to the case assignee and a notification to the Incident Response Slack channel.
Configure a reaction trigger
To configure a playbook to react to specific platform events or data modifications, follow these steps:
- Create a new playbook.
- In the playbook designer, click Open Step Selection and select Triggers.
- Select the Reaction tab to view available event-based triggers for alerts.
- Select the appropriate trigger and drag it to the Drag a trigger over here box in the playbook designer.
- Double-click the trigger to open the side drawer. The parameters available in the Conditions tab automatically update to match the trigger you selected.
Depending on your selected trigger, configure the following logic:
If using Entity Added: Define criteria for triggering based on entities attached to the alert.
- Select Any entity is added to trigger on every new entity.
- Select A specific entity is added to define filtering logic. You can
select from a closed list of entity properties and use logical operators
(
ANDandOR) to configure multiple conditions. For example,Entity.Identifiercontains@google.comANDEntity.TypeisUSERUNIQNAME.
If using Alert Priority Changed: Configure the
Priority changed fromandPriority changed tostates.- You can select a specific priority from the list or use ANY to match any state value.
- You can create multiple state combinations using the OR logical operator
(for example, triggering when priority moves from
MediumtoHighORMediumtoCritical).
If using Alert Custom Field Changed: Select the appropriate field from the menu and configure the
FromandTostates. Use the toggle next to each value to determine if that specific part of the state change is validated.- Toggle Off (Disabled): The system does not check the value for this state. Disabling the toggle effectively matches any value, allowing the trigger to fire regardless of what the field contained before or after the change.
- Toggle On (Enabled): The system checks for a specific value. If the field is left empty while the toggle is on, it signifies a search for an empty string (for example, triggering when a previously blank field is updated).
To reduce the number of unwanted executions, go to the Define additional conditions (optional) section to define criteria that are not directly tied to the reaction trigger itself.
- Example: Configure a playbook to trigger on an alert priority change to
Critical only when case tags don't contain
Test.
- Example: Configure a playbook to trigger on an alert priority change to
Critical only when case tags don't contain
Click Save. The parameter details appear in the trigger description.
Reaction execution modes
Because investigative data can change rapidly, reaction triggers allow you to define how the system handles back-to-back events if a playbook is already running. To select an execution mode, click the Settings tab in the trigger side drawer:
- Restart (default): Terminates the active playbook execution and starts a fresh one immediately using the most current data. Use this mode when you don't want to complete the execution if state changes.
- Queued: Allows the active playbook to finish its current run before processing the next trigger event. Use this mode when you must complete the execution even if the trigger changed already. Queued playbooks appear in the case overview playbooks viewer.
Dynamic reaction placeholders
Reaction triggers utilize specific placeholders to capture the exact snapshot of the trigger at the moment of modification. This ensures your playbook logic remains accurate even if the alert data changes again while the playbook is mid-execution:
- State Changes: Use
[trigger.from_state]and[trigger.to_state]to capture property shifts (e.g., capture old and new priority values). - Event-Specific Details: Use
[trigger.EntityIdentifier]and[trigger.EntityType]to dynamically target a newly attached entity. - Trigger Metadata: Use
[trigger.TriggeredBy]to identify the initiator. For manual UI actions or manual playbook runs, this placeholder displays the full username. If the change is executed by a playbook, it displays System Automation. Use[trigger.DateTime]for the precise event timestamp, formatted as YYYY-MM-DD HH:MM:SS UTC+Offset (for example, 2026-05-11 11:31:55 UTC+01).
Limitations
- Unique playbook limits: You can attach up to 30 unique playbooks per alert.
- Rerun limits: A playbook can be rerun a maximum of 30 times per alert. If
a trigger fires for a playbook already attached, it registers as a
rerun. Subsequent activations are registered asskipped. - Infinite Loop Prevention: Ensure playbooks don't modify the same field that triggers them to avoid loops.
You can now continue building the playbook with actions. For more information, see Manage actions in playbooks.
Need more help? Get answers from Community members and Google SecOps professionals.