2.6.1. Automation Rules
💡 First Principle: An automation rule is a trigger, a set of conditions, and an ordered list of actions. Because every rule is evaluated in a defined sequence against the incident's current state, automation rules act as the SOC's central dispatcher: they decide, in order, what happens to every incident before a human touches it.
Triggers come in three kinds. When incident is created fires for new incidents; in the Defender portal those are incidents created by Defender XDR's correlation engine, including those built from Sentinel alerts. When incident is updated fires on changes such as status, owner, severity, new alerts, comments, tags, or tactics. When alert is created fires only for alerts from scheduled and NRT rules (and, outside the Defender portal, Microsoft security rules); it isn't available for Defender XDR alerts, for which playbooks offer an enhanced alert trigger instead.
Conditions test incident properties such as analytics rule name, severity, title, tags, tactics, and entity properties, using operators like equals, contains, and starts with. Update-trigger rules add Updated by (user, application, AIR, playbook, another automation rule) and state change operators such as "changed to". All conditions must be true for the actions to run.
Actions: assign an owner, change status (closing requires a classification reason), change severity, add tags, add incident tasks (a checklist analysts work through), and run a playbook. Incident-trigger rules can run only incident-trigger playbooks; alert-trigger rules run alert-trigger playbooks.
Order is the property that makes the dispatcher model work. Rules run sequentially, never in parallel, and each trigger type has its own queue (all create-trigger rules run before update-trigger rules). A later rule evaluates the incident after earlier rules have changed it, so rule 2 above sees the severity rule 1 set. Rules with the same order number run in a random order. If a playbook action takes under two minutes, the rule waits for it; longer playbooks continue in the background while the next rule runs. Expiration dates disable a rule automatically, which suits temporary needs such as suppressing alerts during a scheduled penetration test. Once Sentinel is in the Defender portal, rapid successive changes to an incident can be batched, so update-trigger rules may see only the latest change in a short window.
To run playbooks, the Microsoft Sentinel service account needs permission on the playbooks' resource group (2.1.1), granted with the Manage playbook permissions link by someone with Owner rights. Playbooks without that permission appear greyed out in the rule editor.
⚠️ Exam Trap: "A rule that closes incidents from a test rule must run before the rule that assigns owners and runs the paging playbook" is an order question: give the closing rule the lower order number. "Automatically close alerts from penetration testing until Friday" is an automation rule with an expiration date.
Reflection Question: Two automation rules both trigger on incident creation: rule A sets severity to High for incidents from a specific analytics rule, and rule B runs a paging playbook when severity equals High. Which order must they have, and what happens if they're reversed?
