Lesson 9 — Microsoft Sentinel Automation Rules
Microsoft Sentinel incidents should not always require the same manual preparation before an analyst can begin investigating.
Automation rules help the SOC handle repeatable incident actions such as assigning owners, adding tags, changing severity, updating status and triggering playbooks.
In this lesson, you will learn how automation rules support consistent triage and response workflows without replacing analyst judgement.
What you will learn
This lesson explains how automation rules help standardise Sentinel incident handling.
Learning objectives
After completing this lesson, you should understand how Microsoft Sentinel automation rules support SOC operations.
- Explain what an automation rule does.
- Understand the difference between analytics rules, automation rules and playbooks.
- Identify common incident actions that can be automated.
- Understand rule order and conditions.
- Recognise automation mistakes that can damage incident quality.
The problem this solves
SOC analysts often repeat the same incident preparation steps: assign an owner, add a tag, adjust severity, change status or notify a team.
Automation rules reduce repetitive work and help incidents arrive in a more consistent state for investigation.
What is a Microsoft Sentinel automation rule?
A Microsoft Sentinel automation rule performs actions when an incident is created or updated. It helps standardise incident handling by applying conditions and then running actions against matching incidents.
Automation rules should prepare the investigation, not hide it. Use automation to reduce friction, but keep the evidence visible for analysts.
Automation rule workflow
Automation rules sit after detection and before or during analyst triage.
Automation rules vs analytics rules
Analytics rules detect suspicious activity and can create alerts or incidents.
Automation rules act on incidents after they are created or updated. They do not replace detection logic.
Automation rules vs playbooks
Automation rules define when actions should happen.
Playbooks perform more advanced response logic using Azure Logic Apps, such as sending notifications, creating tickets or calling external APIs.
Common automation actions
- Assign an owner or team.
- Add a tag such as Phishing, Identity or Endpoint.
- Change incident severity.
- Change incident status.
- Add a comment with triage guidance.
- Run a playbook.
Conditions
Conditions control which incidents the automation rule applies to.
For example, a rule might only apply when the incident provider is Microsoft Defender XDR, the severity is high, or the title contains phishing.
Rule order matters
Automation rules can run in a defined order.
If multiple rules apply to the same incident, the order can affect which tags, owners, statuses or playbooks are applied.
Tags
Tags make incidents easier to filter, route and report on.
Examples include Phishing, Identity, Endpoint, Privileged Access, Malware, Suspicious Login and False Positive Candidate.
Real-world phishing example
A phishing incident is created from Defender XDR evidence. Instead of leaving the incident unassigned, an automation rule prepares it for triage.
| Automation action | Why it helps |
|---|---|
| Add Phishing tag | Makes the incident easier to filter and report. |
| Assign to email security queue | Routes the incident to the right analysts. |
| Set severity to High when VIP user is involved | Escalates cases with higher business risk. |
| Run notification playbook | Sends a Teams or ticketing alert to the SOC. |
When to automate
Automate predictable, low-risk preparation steps.
Good candidates include tagging, routing, comments, notifications and enrichment steps that do not make irreversible decisions.
When not to automate
Be careful with automation that closes incidents, suppresses evidence or changes severity too aggressively.
If the action could hide a real attack or remove analyst visibility, it needs strong testing and approval.
Agent Foskett investigation tip
Let automation prepare the case, route it correctly and enrich the evidence. Let the analyst decide what the evidence means.
Common mistake
A common mistake is automatically closing incidents before analysts understand why they fired.
Closing false positives can be useful, but only after the logic has been tested, documented and monitored carefully.
What to document
- Rule purpose
- Trigger conditions
- Actions performed
- Expected incident types
- Owner or maintainer
- Rollback or disable plan
Agent Foskett takeaway
Analytics rules create detections.
Automation rules prepare and route incidents.
Playbooks perform deeper automated workflows.
Related Agent Foskett learning
Continue learning
Microsoft Sentinel Automation Rules
Microsoft Sentinel automation rules help SOC teams assign incident owners, add tags, change severity, update status, add comments and trigger playbooks when incidents are created or updated.
Microsoft Sentinel Lesson 9
This Agent Foskett Microsoft Sentinel Academy lesson explains automation rules, incident conditions, rule order, tags, owner assignment, severity changes, status changes, playbooks and SOC incident workflows.
