Use reaction triggers in playbooks

Supported in:

A reaction trigger acts as a post-ingestion trigger configured during the initial playbook setup. While standard triggers execute immediately upon ingestion, reaction triggers automate playbooks based on real-time modifications or specific events that occur during an active investigation.

The availability of specific reaction triggers depends on the playbook scope. When configuring a playbook, selecting the Alert scope displays alert-level event triggers, while selecting the Case scope displays case-level triggers.

By introducing event-based logic, reaction triggers eliminate the need 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 at both the alert and case level:

Automate enrichment for newly discovered entities (Alert scope)

  • Goal: Ensure all entities associated with an investigation are automatically enriched, even if they are added after initial alert ingestion.
  • Scenario: A new entity is attached to an active investigation.
  • Outcome: The Entity Added reaction trigger detects the new entity and automatically executes an enrichment playbook to provide immediate reputation data.

Dynamic incident escalation and notification (Alert scope)

  • Goal: Automatically notify senior stakeholders when the severity of an investigation increases.
  • Scenario: An alert priority changes 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.

Cross-platform ticket synchronization (Case scope)

  • Goal: Maintain strict alignment between the platform and external IT service management (ITSM) platforms during ownership shifts.
  • Scenario: A security case is reassigned from a general queue to a specialized SOC role or user.
  • Outcome: The Case Assignee Changed reaction trigger fires, automatically updating the owner field in the corresponding external ticketing system and sending an operational summary to the new owner.

Available reaction triggers

The options available under the Reaction tab dynamically filter based on the operational scope selected during playbook setup:

Alert scope reaction triggers

When a playbook is configured with an Alert scope, you can select from the following event-based triggers:

  • Entity Added: Fires when a new entity is attached to an active alert after its initial ingestion.
  • Alert Priority Changed: Fires when an analyst or system workflow modifies the priority level of the alert.
  • Alert Custom Field Changed: Fires when a designated alert-level custom field or contextual value updates.

Case scope reaction triggers

When a playbook is configured with a Case scope, the menu displays triggers that monitor the overarching case container:

  • Case Assignee Changed: Fires when ownership shifts between analysts or SOC roles.
  • Case Priority Changed: Fires when the global severity or priority level of the case updates.
  • Case Stage Changed: Fires when a case transitions between phases of the investigation lifecycle (such as moving from Triage to Containment).
  • Custom Case Field Changed: Fires when a case-level custom field or case context value updates.

Configure a reaction trigger

To configure a playbook to react to specific platform events or data modifications, follow these steps:

  1. Click Add New Playbook or Block to create a new playbook.
  2. In the Create New dialog, select the playbook Scope:
    • Select Alert to configure alert-level event triggers.
    • Select Case to configure case-level triggers.
  3. Click Create.
  4. In the Step Selection panel, select Triggers.
  5. Select the Reaction tab to view available event-based triggers for the selected scope.
  6. Select the appropriate trigger and drag it to the trigger target area in the playbook designer.
  7. Double-click the trigger to open the side drawer. The parameters available in the Conditions tab automatically update to match the trigger you selected.

  8. Depending on your selected trigger and playbook scope, configure the following logic:

    • If using Entity Added (Alert scope): Define criteria for triggering based on new entities that were added to the alert post-ingestion.

      • 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 list of entity properties and use logical operators (AND and OR) to configure multiple conditions. For example, Entity.Identifier contains @google.com AND Entity.Type is USERUNIQNAME.

    • If using Alert Priority Changed (Alert scope) or Case Priority Changed (Case scope): Configure the Priority changed from and Priority changed to states.

      • 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 Medium to High OR Medium to Critical).

    • If using Alert Custom Field Changed (Alert scope) or Custom Case Field Changed (Case scope): Select the appropriate field from the menu and configure the From and To states. 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).

    • If using Case Assignee Changed (Case scope): Configure the Assignee changed from and Assignee changed to parameters to track ownership shifts. You can isolate shifts between specific analysts or SOC roles.

    • If using Case Stage Changed (Case scope): Configure the Stage changed from and Stage changed to parameters to detect when a case transitions between different phases of the investigation lifecycle (such as moving from Triage to Containment).

  9. 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 the case priority is also set to High.

  10. 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 the 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 has already changed. Queued playbooks appear in the case overview playbooks viewer.

Dynamic reaction placeholders

Reaction triggers use 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.

Limitations

  • Unique playbook limits: You can attach up to 30 unique playbooks per alert or case.
  • Rerun limits: A playbook can run a maximum of 30 times per alert or case. If a trigger fires for a playbook already attached, it registers as a rerun. Subsequent activations are registered as skipped.
  • Infinite loop prevention: Ensure playbooks do not 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.