Sentinel Automation: Rules & Playbooks
Automate your SOC response with Sentinel automation rules and Logic App playbooks. Learn when to use each, how to configure them, and how they work together for SOAR.
SOAR: the automation layer
Think of a restaurant kitchen. When an order comes in, you do not want the head chef personally handling every single ticket. Simple orders (toast, salad) should be routed automatically. Complex orders (the tasting menu) need the chef’s attention.
In Sentinel, automation rules are the ticket routing system — they automatically assign incidents, change severity, run playbooks, or close false positives based on conditions. Playbooks are the recipes — Logic Apps that take specific actions like sending a Teams message, blocking an IP, or enriching an alert with threat intel.
Together, they form SOAR (Security Orchestration, Automation, and Response) — your kitchen runs itself for the routine work.
Automation rules
Automation rules run every time an incident is created or updated that matches their conditions.
What automation rules can do
| Action | Example |
|---|---|
| Assign owner | Auto-assign phishing incidents to the email security analyst |
| Change severity | Escalate incidents involving executive accounts to High |
| Add tags | Tag incidents from specific data connectors for tracking |
| Run a playbook | Trigger enrichment or notification workflows |
| Close incident | Auto-close known false positives with a classification |
| Suppress | Prevent incident creation for specific conditions |
Automation rule structure
Every automation rule has:
- Trigger — when to evaluate (incident created, incident updated, alert created)
- Conditions — what to match (analytics rule name, severity, entities, tags, etc.)
- Actions — what to do (assign, tag, run playbook, close)
- Order — rules run in the configured order (1, 2, 3…). All matching rules execute — order determines priority when multiple rules try to set the same property (e.g., assign to different analysts). Higher-order rules can override lower-order ones for conflicting actions.
- Expiration — optional end date (useful for temporary suppressions)
Scenario: Anika's automation rules for 40 clients
Anika at Sentinel Shield configures automation rules per client workspace:
- Rule 1 (Order 1): If analytics rule = “Known false positive — backup server” → close incident as Benign Positive
- Rule 2 (Order 2): If severity = High AND entity contains “CEO” or “CFO” → assign to Wei (Tier 2) + change severity to High + run “Notify-VIP-Incident” playbook
- Rule 3 (Order 3): If severity = Medium → assign to the on-call analyst rotation
- Rule 4 (Order 4): All remaining incidents → add tag “Unassigned” for triage review
Order matters: Rule 1 closes false positives before Rule 2 checks for VIP involvement.
Playbooks
Playbooks are Azure Logic Apps that perform automated actions when triggered by Sentinel.
Common playbook patterns
| Pattern | What It Does | Services Used |
|---|---|---|
| Enrichment | Look up entities in VirusTotal, AbuseIPDB, Shodan | External threat intel APIs |
| Notification | Post to Teams channel, send email, create ServiceNow ticket | Teams, Outlook, ServiceNow |
| Containment | Block IP in firewall, disable user, isolate device | Defender XDR, Entra ID, firewall API |
| Remediation | Reset password, revoke sessions, quarantine mailbox | Entra ID, Exchange Online |
| Sync | Bi-directional incident sync between Sentinel and ITSM tools | ServiceNow, Jira, PagerDuty |
Playbook triggers
| Trigger | When It Fires | Use Case |
|---|---|---|
| Microsoft Sentinel Incident | When an automation rule triggers the playbook | Most common — incident-based automation |
| Microsoft Sentinel Alert | When a specific alert fires | Alert-level enrichment before incident creation |
| Microsoft Sentinel Entity | When an entity is investigated | On-demand enrichment during investigation |
| Feature | Automation Rules | Playbooks |
|---|---|---|
| What they are | Lightweight condition-action rules in Sentinel | Azure Logic Apps workflows |
| Complexity | Simple — no code, dropdown configuration | Complex — multi-step workflows with connectors |
| Actions | Assign, tag, change severity, close, run playbook | Anything Logic Apps can do (hundreds of connectors) |
| External integration | No — Sentinel actions only | Yes — Teams, email, ServiceNow, APIs, etc. |
| Who creates them | SOC analysts and leads | Automation engineers and developers |
| Required role | Sentinel Contributor | Logic App Contributor + Sentinel Playbook Operator |
Exam tip: who can create what
The exam tests role-based access for automation:
- Automation rules → requires Sentinel Contributor role
- Playbooks (create/edit) → requires Logic App Contributor role
- Playbooks (run) → requires Sentinel Playbook Operator role
A common trap: a Sentinel Contributor can create automation rules that reference playbooks, but cannot create or edit the playbooks themselves. If the question says “create a playbook,” the answer is Logic App Contributor.
Building a playbook step by step
- Create a Logic App in Azure (Consumption tier for Sentinel playbooks)
- Add the Sentinel trigger (incident trigger is most common)
- Add actions — parse the incident, extract entities, call external APIs
- Add Sentinel actions — update incident, add comment, change severity
- Authorise connections — each connector needs credentials (managed identity recommended)
- Test — trigger manually from an incident in Sentinel
- Connect to automation rule — the rule calls the playbook automatically
Scenario: Dev builds an enrichment playbook
Dev, the automation engineer at Pacific Meridian, builds an enrichment playbook:
Trigger: Microsoft Sentinel Incident (when automation rule fires)
Steps:
- Parse incident entities — extract IP addresses
- For each IP → call VirusTotal API → get reputation score
- For each IP → call AbuseIPDB → get abuse confidence score
- Add a comment to the Sentinel incident with enrichment results
- If any IP has VirusTotal score greater than 5 → change incident severity to High
- Post summary to the SOC Teams channel
James creates an automation rule: “If analytics rule = Suspicious Outbound Connection → run Dev’s enrichment playbook.”
Anika needs phishing incidents at a client to automatically post a message to the SOC Teams channel. What should she configure?
Dev at Pacific Meridian creates a Logic App playbook for incident enrichment. He wants it to run automatically when high-severity incidents are created. What else needs to be configured?
🎬 Video coming soon
Next up: Automation handles the routine. Now let’s build the detections — custom detection rules in Defender XDR that turn your hunting queries into always-on monitors.