SA1.4 Your First Playbook

5 hours · Module 1 · Free
YOUR FIRST PLAYBOOK — INCIDENT ENRICHMENT + TEAMS NOTIFICATIONTRIGGERIncident createdEXTRACTAccount entityQUERYLast 10 sign-insCOMMENTAdd to incidentTEAMSPost to SOCSTEP-BY-STEP BUILDStep 1: Create Logic App (Consumption) → Name: SA-Playbook-Enrichment-FirstStep 2: Add trigger: "When Microsoft Sentinel incident is created" → connect to workspaceStep 3: Add action: "Entities - Get Accounts" (Sentinel connector) → extract account from incidentStep 4: Add action: "Run query and list results" (Log Analytics) → KQL for last 10 sign-insStep 5: Add action: "Add comment to incident" (Sentinel) → format enrichment results as HTML tableStep 6: Add action: "Post message" (Teams) → send incident summary to SOC channelStep 7: Enable managed identity → grant Sentinel Responder + Log Analytics Reader permissionsStep 8: Connect to automation rule (SA1.3 Rule 4) → test with sample incidentTotal build time: 30-45 minutes (first time). 15 minutes once familiar with the designer.

Figure SA1.4 — Your first playbook: 6 actions that transform a raw alert into an investigation-ready, enriched incident with Teams notification.

Operational Objective
You have built automation rules. Now you build the first Logic App playbook — the enrichment playbook that transforms raw incidents into investigation-ready packages. This playbook triggers when a High or Critical incident is created, extracts the account entity, queries the user's last 10 sign-ins from SigninLogs, adds the results as a formatted incident comment, and posts a summary to the SOC Teams channel. It is Tier 1 automation — zero blast radius, immediate analyst value.
Deliverable: A deployed, tested Sentinel playbook that enriches incidents with user sign-in history and posts to Teams. Your first production Logic App.
⏱ Estimated completion: 45 minutes

Prerequisites

Before building, confirm you have:

  1. A Sentinel workspace with at least one analytics rule generating incidents (the rule does not need to fire frequently — you will test with manual incidents if needed).
  2. Permissions to create Logic Apps in your Azure subscription (Contributor role on the resource group).
  3. A Teams channel for SOC notifications (create one if it does not exist — name it “SOC Alerts” or “Security Automation”).
  4. Log Analytics Reader role on the Sentinel workspace for the Logic App’s managed identity (you will configure this during the build).

If you do not have an Azure subscription or Sentinel workspace, follow the screenshots and conceptual walkthrough. The methodology transfers to any Sentinel environment. SA13 (capstone) assumes you have a working workspace.

Step 1: Create the Logic App

Navigate to portal.azure.com → Create a resource → search “Logic App” → Create.

Basics tab:

  • Subscription: your subscription
  • Resource group: the same group as your Sentinel workspace (simplifies RBAC)
  • Logic App name: SA-Playbook-Enrichment-First
  • Region: same region as your Sentinel workspace
  • Plan type: Consumption (pay-per-execution, cheapest for low-to-moderate volume)
  • Enable log analytics: Yes (connect to the same Log Analytics workspace as Sentinel — this enables health monitoring KQL queries)

Click “Review + Create” → Create. Wait 30-60 seconds for deployment to complete. Click “Go to resource.”

Step 2: Configure managed identity

Before building the workflow, set up the authentication that the playbook needs.

Navigate to the Logic App → Settings → Identity → System assigned → Status: On → Save.

Azure creates a system-assigned managed identity for this Logic App. You need to grant it two permissions:

Permission 1: Microsoft Sentinel Responder on the Sentinel workspace. Navigate to your Sentinel workspace → Access control (IAM) → Add role assignment → Role: “Microsoft Sentinel Responder” → Members: select the Logic App’s managed identity → Review + assign. This permission allows the playbook to read incidents, add comments, and modify incident properties.

Permission 2: Log Analytics Reader on the workspace. Same process: Access control (IAM) → Add role assignment → Role: “Log Analytics Reader” → select the Logic App → assign. This permission allows the playbook to run KQL queries against the workspace data.

These two permissions are the minimum required for an enrichment playbook. Containment playbooks (SA5-SA7) will require additional Graph API permissions.

Step 3: Build the workflow

Navigate to the Logic App → Development Tools → Logic App designer.

Action 1: Trigger. The designer opens with a blank canvas. Search for “Microsoft Sentinel” and select the trigger “When Microsoft Sentinel incident is created.” A connection dialog appears — authenticate with managed identity. Select your subscription, resource group, and workspace.

Once connected, the trigger shows the incident payload schema. You now have access to the incident’s properties: title, severity, description, entities, alerts, incident URL, and more.

Action 2: Extract account entity. Click “+ New step” and search for “Microsoft Sentinel.” Select “Entities - Get Accounts.” In the “Entities list” field, select the dynamic content “Entities” from the trigger. This action parses the incident’s entity list and extracts all Account entities into an array.

Action 3: Query sign-in history. Click “+ New step” and search for “Azure Monitor Logs.” Select “Run query and list results.” Configure:

  • Subscription: your subscription
  • Resource group: your Sentinel workspace resource group
  • Resource type: Log Analytics workspace
  • Resource name: your workspace name
  • Query:
1
2
3
4
5
6
7
8
9
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "@{first(body('Entities_-_Get_Accounts'))?['properties']?['upnSuffix']}"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, 
    Status = case(ResultType == 0, "Success", "Failure"),
    MFADetail = tostring(MfaDetail.authMethod),
    RiskLevel = RiskLevelDuringSignIn
| order by TimeGenerated desc
| take 10

This query returns the user’s last 10 sign-ins from the past 24 hours. The =~ operator does case-insensitive matching. The first() function takes the first account entity (most incidents have one account).

Note on the entity expression: The expression @{first(body('Entities_-_Get_Accounts'))?['properties']?['upnSuffix']} extracts the UPN from the first account entity. This is the part that trips up most first-time playbook builders. If entity extraction fails (no Account entity in the incident), this query returns no results rather than erroring — the =~ comparison with a null value returns no matches. SA1.6 covers entity extraction patterns in detail.

Action 4: Add incident comment. Click “+ New step” and search for “Microsoft Sentinel.” Select “Add comment to incident (V3).” Configure:

  • Incident ARM id: select “Incident ARM ID” from the trigger’s dynamic content
  • Incident comment message: build an HTML formatted comment:
<h3>🔍 Enrichment: User Sign-In History (Last 24h)</h3>
<p>Playbook: SA-Playbook-Enrichment-First | Executed: @{utcNow()}</p>
<p><strong>User:</strong> @{first(body('Entities_-_Get_Accounts'))?['properties']?['upnSuffix']}</p>
<p><strong>Sign-ins found:</strong> @{length(body('Run_query_and_list_results')?['value'])}</p>
<table border="1" cellpadding="4">
<tr><th>Time</th><th>IP</th><th>Location</th><th>App</th><th>Status</th><th>MFA</th><th>Risk</th></tr>
@{body('Run_query_and_list_results')?['value']}
</table>
<p><em>Auto-enriched by Sentinel Automation. Tag: enriched.</em></p>

The table formatting will need refinement — the raw query results are JSON, not HTML table rows. For your first playbook, a simple JSON dump in a <pre> block works. SA2 builds production-quality HTML formatting.

Action 5: Post to Teams. Click “+ New step” and search for “Microsoft Teams.” Select “Post message in a chat or channel.” Configure:

  • Post as: Flow bot
  • Post in: Channel
  • Team: select your SOC team
  • Channel: select your SOC Alerts channel
  • Message: 🚨 New @{triggerBody()?['object']?['properties']?['severity']} incident: @{triggerBody()?['object']?['properties']?['title']} — Enrichment applied. View in Sentinel: @{triggerBody()?['object']?['properties']?['incidentUrl']}

A Teams connection is created using your account credentials (not managed identity — the Teams connector requires user-delegated auth). This means your account must remain active for the Teams action to work. For production, use a shared service account.

Action 6: Update tag. Click “+ New step” → “Microsoft Sentinel” → “Update incident.” Set the tag to “enriched” (replacing “enrichment-pending” if you set that in the automation rule).

Step 4: Save and test

Click “Save” in the designer. The Logic App is now deployable but not yet connected to a Sentinel trigger.

Connect to the automation rule. Navigate to Sentinel → Automation → edit your playbook trigger rule (SA1.3 Rule 4, order 200). In the “Run playbook” action, select “SA-Playbook-Enrichment-First.” The connection between the automation rule and the playbook is established.

Test with a manual incident. Create a test incident in Sentinel that matches the automation rule conditions (severity High, or matching analytics rule name). Within seconds, the automation rule should trigger the playbook. Check:

  1. Does the Logic App show a run in run history? (Logic App → Run history)
  2. Is the run status “Succeeded”?
  3. Does the incident have an enrichment comment?
  4. Did the Teams channel receive a message?
  5. Is the incident tagged “enriched”?

If any step failed, open the run history and click on the failed run. Logic Apps show each step’s input and output — the failure message tells you exactly what went wrong. Common first-playbook failures:

  • Permission error on KQL query: The managed identity does not have Log Analytics Reader. Grant the role and re-run.
  • Entity extraction returns empty: The test incident has no Account entity mapped. Create a test incident from an analytics rule that maps Account entities, or use a different entity extraction approach.
  • Teams connection expired: Re-authorize the Teams connection in the Logic App’s API connections blade.
⚠ Compliance Myth: "Building a Logic App requires Azure developer certification"

The myth: Logic Apps are a developer tool requiring Azure development expertise (AZ-204 or equivalent).

The reality: The Logic App designer is a no-code/low-code tool. The steps above — adding connectors, selecting actions, configuring dynamic content — require zero coding. The KQL query is the most technical element, and you already know KQL from Mastering KQL and Detection Engineering. Complex playbooks (SA5-SA7 containment) use expressions and JSON parsing that are more technical, but the fundamentals you just built are achievable by any SOC analyst who can navigate the Azure portal.

Decision point: Your playbook works in testing. Should you deploy to production immediately? For a Tier 1 enrichment playbook — yes. The blast radius is zero. The worst case: the enrichment comment contains incorrect data (which the analyst can verify) or the playbook fails silently (which monitoring will detect). Deploy now, monitor for a week, fix any issues that arise in production. Do not wait for perfect — deploy and iterate. The 500 alerts per day that arrive without enrichment while you perfect the playbook are 500 missed opportunities for automation value.

Try it: Build and deploy the playbook

Follow the steps above in your Azure environment. Target: complete the build and first successful test run in under 45 minutes.

After the playbook runs successfully:

  1. Open the enriched incident in Sentinel. Read the enrichment comment. Is it useful? What would you add?
  2. Check the Teams notification. Is it informative enough for the analyst to prioritise without opening Sentinel?
  3. Check the Logic App run history. How long did the playbook take? (Target: under 30 seconds for a 10-row KQL query.)
  4. Identify the next enrichment source you would add (IP reputation? User risk score? Device compliance?). SA2 builds the full pipeline.
Your enrichment playbook runs successfully on a test incident but fails in production with the error "No account entities found in incident." What is the most likely cause?
The managed identity does not have permission to read entities. Entity extraction does not require additional permissions — the incident trigger payload includes entities. The error means the incident has no Account entity mapped, not that the playbook cannot read it.
The production analytics rule does not map Account entities in its entity mapping configuration. Your test incident (created manually or from a different rule) had Account entities, but the production rule does not include Account in its entity mapping. Fix: edit the analytics rule → Entity mapping → add Account entity mapping to the rule's output. This is the most common "works in test, fails in production" issue for enrichment playbooks.
The user does not exist in Entra ID. Entity extraction succeeds or fails based on the incident payload, not the user's existence in Entra ID. The playbook extracts the entity from the incident; it does not validate the entity against the directory at this step.
The playbook needs to use "Entities - Get IPs" instead of "Entities - Get Accounts." The playbook is designed to enrich based on Account entities (for user sign-in history). IP enrichment uses a different extraction action. The error says no Account entities exist — the fix is in the analytics rule's entity mapping, not the playbook's extraction action.

Where this goes deeper. SA1.5 covers authentication in depth — managed identity permission grants, Key Vault for third-party API keys, and least-privilege design. SA1.6 covers entity extraction patterns that handle missing entities, multiple entities, and non-standard entity types. SA2 builds the full enrichment pipeline with 6 enrichment sources, parallel execution, and production-quality HTML formatting. What you built here is the foundation — SA2 makes it comprehensive.

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus