What’s new: Centrally manage automated response to alerts with automation rules

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

A playbook in Microsoft Sentinel is a collection of actions that can be run as a routine. It can be run manually or set to run automatically in response to specific alerts or incidents. Previously, playbooks designated to run in response to alerts could be automatically invoked only by an analytics rule. Now, you can use automation rules to centrally manage and run your alert-trigger playbooks in addition to your incident-trigger playbooks.


Incident-based or alert-based automation?

Now that both incident automation and alert automation are handled centrally by automation rules in addition to playbooks, how should you choose when to use which?

For most use cases, incident-triggered automation is the preferable approach. In Microsoft Sentinel, an incident is a “case file” – an aggregation of all the relevant evidence for a specific investigation. It’s a container for alerts, entities, comments, collaboration, and other artifacts. Unlike alerts which are single pieces of evidence, incidents are modifiable, have the most updated status, and can be enriched with comments, tags, and bookmarks. The incident allows you to track the attack story which keeps evolving with the addition of new alerts.

For these reasons, it makes more sense to build your automation around incidents. So the most appropriate way to create playbooks is to base them on the Microsoft Sentinel incident trigger in Azure Logic Apps.

The main reason to use alert-triggered automation is for responding to alerts generated by analytics rules which do not create incidents (that is, where incident creation has been disabled in the Incident configuration tab of the analytics rule wizard). A SOC might decide to do this if it wants to use its own logic to determine if and how incidents are created from alerts, as well as if and how alerts are grouped into incidents. For example:

  • A playbook can be triggered by an alert that doesn’t have an associated incident, enrich the alert with information from other sources, and based on some external logic decide whether to create an incident or not.
  • A playbook can be triggered by an alert and, instead of creating an incident, look for an appropriate existing incident to add the alert to. (Learn more about incident expansion)
  • A playbook can be triggered by an alert and notify SOC personnel of the alert, so the team can decide whether or not to create an incident.
  • You are using an external ticketing system for incidents creation and management, and need playbooks for creating a ticket for each new alert

Note: Alert-triggered automation is available only for alerts created by Scheduled analytics rules. Microsoft Security alerts are not supported.


Migrate your alert-triggered playbooks from analytics rules to automation rules


Full details can be found here: Migrate your Microsoft Sentinel alert-trigger playbooks to automation rules


Why to migrate

If you already have configured alert playbooks attached to analytics rules, we strongly encourage you to move these playbooks to automation rules. Doing so will give you the following advantages:

  • Manage all your automations from a single display, regardless of type (“single pane of glass”).
  • Define a single automation rule that can trigger playbooks for multiple analytics rules, instead of configuring each analytics rule independently.
  • Define the order in which alert playbooks will be executed.


How to migrate

If you’re migrating a playbook invoked by a single analytics rule, follow these instructions.

If you’re migrating a playbook invoked by more than one analytics rule, follow the instructions under Create a new automation rule from portal.

  1. From the main navigation menu, select Analytics.
  2. Under Active rules, find an analytics rule already configured to run a playbook.
  3. Select Edit.


  4. Select the Automated Response tab.
  5. Playbooks directly configured to run from this analytics rule can be found under Alert automation (classic).



  1. Select + Add new under Automation rules (in the upper half of the screen) to create a new automation rule.
  2. In the Create new automation rule panel, under Trigger, select when alert is created (Preview).


  3. Under Actions, select your playbook.


  4. Click Apply. You will now see the new rule in the automation rules grid.



  1. Remove the playbook from the Alert automation (classic) section.




  1. Review and update the analytics rule to save your changes.


Create a new automation rule from portal

If you’re migrating a playbook invoked by more than one analytics rule, follow these instructions:

  1. From the main navigation menu, select Automation.
  2. From the top menu bar, select Create -> Automation rule
  3. In the Create new automation rule panel, in the trigger drop-down, select when alert is created (preview)
  4. Under Conditions, select the analytics rules you want to run a particular playbook or a set of playbooks on.
  5. Under Actions, for each playbook you want this rule to invoke, add the Run playbook action and select from the list of available playbooks in the drop-down. Order the actions according to the order in which you want the playbooks to run.


  6. Select Apply to save the automation rule.
  7. Edit the analytics rule or rules that invoked these playbooks (the rules you specified under Conditions), removing the playbook from the Alert automation (classic) section of the Automated response tab.


Manage automation rules

Three trigger types are now available in the automation rules grid:

  • Incident created
  • Incident updated
  • Alert created

You can use the Trigger filter to see only one of them.

Please note that each trigger has its own chain of ordered rules that will run one after the other.



Learn more




Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.