Microsoft Sentinel Automation Rules and Playbooks: How to Automate Incident Response Without a Full SOAR

Automation rules run before a playbook and can take immediate action on incidents without a Logic Apps execution. Create them in Sentinel > Automation > Create > Automation Rule. Useful automation rules that require no code: Auto-close low-fidelity incidents from specific rules -- if you have an analytic rule that generates frequent false positives and you have not yet tuned it, create an automation rule that closes incidents from that specific rule with status 'False Positive' and a note explaining why. This prevents analyst queue pollution while the rule is being tuned. Change severity based on entity context -- if an incident involves a user in your 'High Priority Executives' watchlist, automatically raise severity to High regardless of the base rule severity. Add an owner based on incident source -- route cloud incidents to the cloud security team, endpoint incidents to the endpoint team, using automation rules to assign ownership immediately on creation. Automation rules are evaluated in order (by priority) and can include up to 50 conditions per rule using AND/OR logic.

The most universally useful playbook enriches every incident with context about the user entity involved. Build in Logic Apps: Trigger: Sentinel incident trigger (When Azure Sentinel incident creation rule was triggered). Action 1: Get Entities - Accounts (Sentinel built-in connector). Action 2: For each account entity, call the Microsoft Graph API to get user details: GET https://graph.microsoft.com/v1.0/users/{UserPrincipalName}?$select=displayName,jobTitle,department,manager,accountEnabled,lastPasswordChangeDateTime,signInSessionsValidFromDateTime. Action 3: Add a comment to the Sentinel incident with the enrichment data -- department, job title, manager name, whether the account is enabled, last password change date. Action 4: If accountEnabled=false, auto-close as False Positive (disabled accounts cannot sign in). This playbook transforms every incident from 'user JSmith triggered alert' to 'Jane Smith, Finance Manager, reports to CFO, account enabled, password changed 2 years ago' -- context that informs triage decisions immediately. Connect the playbook to an automation rule that runs it on every incident.

Create a playbook that alerts the security team via Microsoft Teams when a high-severity incident is created. Trigger: Sentinel incident trigger. Condition: if incident severity = High or Critical. Action: Post a Teams adaptive card to the security team channel with: incident name and description, severity and confidence, affected user and host entity names, link to the Sentinel incident for investigation, and two action buttons ('Acknowledge' and 'Escalate to CISO'). When an analyst clicks Acknowledge in Teams, another Logic Apps flow marks the incident as Active and assigns it to the acknowledging analyst (using the Teams approval action to capture the responding user identity). This replaces email alert chains with a structured Teams workflow where every high-severity incident has a documented acknowledgment and owner. The Teams adaptive card can be sent within seconds of incident creation -- faster than any manual monitoring workflow.

For incidents where an analyst confirms device compromise (typically after reviewing evidence and escalating the incident to Active status with the 'True Positive' label), create a playbook that calls the Microsoft Defender for Endpoint API to isolate the device with one click. Trigger: Sentinel incident trigger when Status = Active AND Classification = TruePositive AND Severity = High. Action 1: Get Entities - Hosts (extract the device entity from the incident). Action 2: Call the MDE API: POST https://api.securitycenter.microsoft.com/api/machines/{machineId}/isolate with body {"Comment":"Isolated via Sentinel playbook due to confirmed compromise", "IsolationType":"Full"}. The playbook needs a managed identity or service principal with the Machine.Isolate application permission in MDE. Action 3: Post a Teams notification confirming the isolation action was taken, including the machine name and time of isolation. This converts a manual 5-step process (find the device in MDE, look up the machine ID, call the API, confirm isolation, log the action) into a single classification step in Sentinel. The isolation action should be triggered by analyst confirmation (incident reclassification), not automatically on alert creation -- you do not want to isolate devices on false positive incidents.

Playbooks run as Logic Apps with either a Managed Identity (recommended) or a service principal. The Managed Identity needs: Microsoft Sentinel Responder role (to add comments and update incidents), Graph API User.Read.All (for user enrichment), MDE Machine.Isolate (for device isolation), and whatever permissions specific actions require. Assign the Managed Identity permissions in the Azure portal IAM settings for each resource. Testing: use the Sentinel playbook test feature (Run playbook on a test incident) before linking to live automation rules. Check the Logic Apps run history for errors and execution details. Cost: Logic Apps consumption tier charges per action execution. A user enrichment playbook running on 100 incidents per day with 5 actions each costs approximately $0.005 per execution -- roughly $2.50 per month for 100 daily incidents. Device isolation playbooks that run less frequently cost pennies per month. Sentinel automation is extremely cost-effective compared to dedicated SOAR licensing.