L12. Automation and SOAR: Playbooks with Logic Apps
Visual workflow edition
Worked example, diagrams and a question with time to think. Synthetic American-English narration; examples are fictional. Reviewed October 2026.
Read the video transcript
A new incident arrives, and automation could disable an account immediately. Should it? First ask what evidence supports the action and what could break. We'll separate automation rules from playbooks, then build a response flow that enriches the incident before a high-impact decision.
An automation rule evaluates supported conditions and coordinates incident or alert handling. A playbook is a workflow built with Azure Logic Apps that can perform connected steps. Calling a playbook does not automatically grant its connections permission to act. Trigger configuration, workflow identity, and target-service permissions each need attention.
Imagine an incident involving a suspicious source address. The workflow adds relevant context, records a recommendation, and sends a decision to the responsible responder. If the response is approved, it performs a narrowly scoped action. The design keeps evidence gathering separate from a disruptive change. Your organization's process determines which actions can safely run automatically.
External services can fail or return slowly. A workflow may retry, and a repeated action can have unintended effects. Design for duplicate execution and partial completion. Record what happened at each step, and provide a useful failure path. A green workflow run is not sufficient if the intended target never changed state.
Use the least privilege needed for the specific action and test against an approved target. Check both a permitted action and an expected denial. Confirm the resulting state and record the evidence. Do not test by disrupting a production account merely to see whether automation works. A controlled lab can validate the workflow safely.
The automation rule triggers, but the playbook cannot update the target service. What should you inspect before granting a broad administrator role? Pause and name the separate permission boundaries.
Inspect the trigger permissions, connection identity, and target-service authorization. Grant only the required capability after confirming the cause. The core pattern is evidence, decision, scoped action, and verification. Automation should make a good response repeatable, not make an uncertain response happen faster without an accountable owner.
Course outlineLesson 12 of 18
Sentinel SOAR capabilities automate incident response through automation rules and playbooks built on Azure Logic Apps. This lesson covers automation rule triggers, playbook architecture, and common automation patterns for the SC-200 exam.
Automation in Sentinel
Sentinel provides two automation mechanisms:
| Feature | Purpose | Complexity |
|---|---|---|
| Automation rules | Lightweight incident management (assign, tag, close, trigger playbook) | Low |
| Playbooks | Complex workflows with external integrations (Logic Apps) | Medium to High |
Automation Rules
Automation rules support incident-created, incident-updated and alert-created triggers. Available conditions and actions depend on the trigger. They execute in order of priority and support these actions:
- Assign owner: Route incidents to specific analysts or teams
- Change status: Auto-close known benign incidents
- Change severity: Escalate or de-escalate based on conditions
- Add tags: Categorize incidents for reporting
- Run playbook: Trigger a Logic Apps workflow
Conditions can filter on: incident provider, analytics rule name, severity, title contains, entity values, tags, and custom details. Exam tip: Automation rules execute in priority order (lowest number first). Later rules evaluate the incident state left by earlier rules. Closing the incident does not automatically stop the sequence; a later rule must still meet its conditions.
Playbooks (Logic Apps)
Playbooks are Azure Logic Apps workflows triggered by Sentinel. They provide the SOAR (Security Orchestration, Automation and Response) layer: Common playbook triggers:
- Microsoft Sentinel incident: Receives incident, alert and entity context; called by an automation rule on incident creation or update
- Microsoft Sentinel alert (Preview): Alert-context trigger for manual alert playbooks; this legacy connector trigger cannot be called by automation rules
- Microsoft Sentinel entity: Runs manually on a selected entity from investigation or hunting; not called by automation rules
- Send notification (email, Teams message, Slack)
- Enrich incident with threat intelligence lookups
- Block IP/URL in firewall or proxy
- Disable user account in Entra ID
- Isolate device via Defender for Endpoint API
- Create ticket in ServiceNow or Jira
- Post to a security channel in Teams
Playbook Architecture
A typical enrichment playbook:
- Trigger: Sentinel incident creation
- Parse entities: Extract IP addresses from the incident
- For each IP: Query VirusTotal or AbuseIPDB API
- Add comment: Write enrichment results to the incident
- Conditional: If any IP is malicious, change severity to High
Key Logic Apps connectors for security playbooks:
| Connector | Use Case |
|---|---|
| Microsoft Sentinel | Read/update incidents, add comments |
| Microsoft Entra ID | Disable accounts, reset passwords |
| Microsoft Defender for Endpoint | Isolate devices, run scans |
| Microsoft Teams | Send notifications, post to channels |
| VirusTotal | File and URL reputation lookups |
| ServiceNow | Create and update tickets |
Managed Identity and Permissions
Playbooks use a managed identity to authenticate to Sentinel and other Azure services. The managed identity needs:
- Microsoft Sentinel Responder role on the workspace (to update incidents)
- Microsoft Sentinel Reader role (if only reading incident data)
- Appropriate permissions on target services (e.g., User Administrator to disable accounts)
Automation Rule + Playbook Pattern
The recommended pattern combines both features:
- Automation rule filters incidents by analytics rule name or severity
- Automation rule triggers the appropriate playbook
- Playbook executes the response workflow
This separation keeps playbook logic clean (no filtering needed) and allows the same playbook to be triggered by multiple automation rules with different conditions.
Portal and Execution Permissions
In the Microsoft Defender portal, go to Microsoft Sentinel > Configuration > Automation. Azure portal automation remains available until its Sentinel support ends after March 31, 2027. Grant the Sentinel service account Microsoft Sentinel Automation Contributor on the playbook resource group so automation rules can run playbooks; this is separate from the playbook managed identity permissions used inside the workflow.
After onboarding Sentinel to the Defender portal, Defender XDR handles correlation instead of Fusion. Microsoft security incident-creation rules are unsupported there; update automation filters to match the unified incident workflow.
Playbook Templates
The Content Hub and Sentinel GitHub repository provide playbook templates for common scenarios:
- Incident enrichment with threat intelligence
- User entity validation and account actions
- IP blocking across multiple firewall vendors
- Automated ticket creation and notification
References
- ✓Automation rules handle lightweight actions (assign, tag, close) and trigger playbooks for complex workflows.
- ✓Automation rules execute in priority order. Later rules evaluate the state left by earlier rules, including status changes.
- ✓Playbooks use incident, alert or entity connector triggers; automation rules invoke incident-trigger playbooks on incident creation or update.
- ✓Playbooks require the Microsoft Sentinel Responder role to update incidents (Reader is not sufficient).
- ✓The recommended pattern combines automation rules for filtering with playbooks for response logic.
- ✓Common playbook actions include enrichment lookups, account disabling, device isolation, and ticket creation.
1. A playbook needs to add comments and change the severity of Sentinel incidents. Which minimum role must the playbook managed identity have?
2. An organization wants to automatically assign all high-severity incidents from the "Brute Force" analytics rule to a specific analyst. Which Sentinel feature should they use?
3. Multiple automation rules match a newly created incident. In what order do they execute?
Keep learning
Use the knowledge check above to test your understanding. You can browse every lesson without signing in; opening another lesson does not mark this one complete.
Next lesson: Workbooks and Threat Hunting →