Lesson 10 — Microsoft Sentinel Playbooks and Logic Apps
Automation rules decide when Sentinel should take action.
Playbooks define what that action actually does.
Microsoft Sentinel playbooks are built with Azure Logic Apps and can send notifications, enrich incidents, create tickets, call external services and support repeatable SOC response workflows.
What you will learn
This lesson explains how Sentinel playbooks use Azure Logic Apps to automate SOC workflows.
Learning objectives
After completing this lesson, you should understand how Microsoft Sentinel playbooks support SOC automation.
- Explain what a Sentinel playbook is.
- Understand how Azure Logic Apps powers playbooks.
- Recognise common triggers, actions and connectors.
- Understand how playbooks are launched.
- Identify permissions and safety considerations.
The problem this solves
SOC teams often repeat the same external actions after incidents are created.
Playbooks help automate tasks such as sending messages, creating tickets, enriching evidence and calling external systems.
What is a Microsoft Sentinel playbook?
A Microsoft Sentinel playbook is an automated workflow built using Azure Logic Apps. It can receive Sentinel incident or alert context, process that information and run actions across Microsoft and third-party services.
A playbook should make the analyst faster, not make the investigation harder to understand. Keep the workflow visible, documented and reversible where possible.
How playbooks fit into Sentinel
Automation rules and playbooks work together to create repeatable response workflows.
Azure Logic Apps
Azure Logic Apps is the workflow engine behind Sentinel playbooks.
It provides triggers, actions, conditions, loops and connectors that allow security workflows to communicate with other services.
Triggers
A trigger starts the playbook.
For Sentinel, a playbook may start when an incident is created, when an incident is updated, when an alert is generated or when an analyst runs it manually.
Actions
- Send a Teams message.
- Send an email.
- Create a ServiceNow or ticketing record.
- Add a comment to the incident.
- Call a REST API.
- Query another service for enrichment.
Connectors
Logic Apps connectors allow the playbook to communicate with other platforms.
Examples include Microsoft Sentinel, Microsoft Teams, Outlook, ServiceNow, Azure Monitor, HTTP, Microsoft Entra ID and many third-party services.
Manual vs automatic execution
Playbooks can be run automatically by automation rules or manually by analysts.
Manual execution is useful during testing or when analyst approval is needed before a response action occurs.
Incident context
Playbooks can receive incident details such as title, severity, status, entities, alerts and comments.
This context allows the workflow to tailor its actions to the specific incident.
Real-world phishing playbook
| Playbook step | Purpose |
|---|---|
| Read incident entities | Identify the user, mailbox, device and URLs involved. |
| Enrich suspicious IP or domain | Add reputation and threat intelligence context. |
| Create ticket | Track the investigation in the service management platform. |
| Send Teams notification | Alert the SOC or email security team. |
| Add incident comment | Record enrichment and ticket details for the analyst. |
Permissions
Playbooks need the correct permissions to access Sentinel incidents and external services.
Too few permissions can cause the workflow to fail. Too many permissions can create unnecessary risk.
Managed identities
Managed identities can help playbooks authenticate to Azure resources without storing passwords or secrets directly in the workflow.
Testing
Test playbooks with controlled incidents before enabling automatic execution.
Confirm each connector, permission, condition and action behaves as expected, including failure paths.
Error handling
Production playbooks should handle failures clearly.
Consider what happens if a connector is unavailable, an API times out or a required entity is missing.
Agent Foskett investigation tip
Start with low-risk actions such as notifications, comments and evidence enrichment. Introduce disruptive response actions only after the workflow is trusted and properly governed.
Common mistake
A common mistake is giving a playbook powerful permissions before the workflow has been fully tested.
Use least privilege and start with actions that are easy to review and reverse.
What to document
- Playbook purpose
- Trigger method
- Services and connectors used
- Permissions required
- Failure handling
- Owner and change process
Agent Foskett takeaway
Automation rules decide when a workflow runs.
Playbooks define what the workflow does.
Good playbooks enrich investigations and reduce repetitive SOC work without hiding the evidence.
Related Agent Foskett learning
Continue learning
Microsoft Sentinel Playbooks and Logic Apps
Microsoft Sentinel playbooks use Azure Logic Apps to automate incident enrichment, notifications, ticketing, comments, API calls and SOC response workflows.
Microsoft Sentinel Lesson 10
This Agent Foskett Microsoft Sentinel Academy lesson explains playbooks, Azure Logic Apps, triggers, actions, connectors, managed identities, permissions, testing and SOC automation.
