SC-200 Microsoft Sentinel Automation: Automation Rules and Playbooks

Automation rules are Microsoft Sentinel's built-in, no-code way to act on incidents and alerts; playbooks are Azure Logic Apps workflows that automation rules (or analysts) run when the response needs logic, external systems or data the rule can't reach. Use an automation rule whenever its native actions are enough, and add a playbook only for what they can't do.

An automation rule has a trigger, conditions and an ordered list of actions. Its native actions change the incident itself: Assign owner, Change status (closing needs a classification), Change severity, Add tags, and Add task. Its other action is Run playbook. Because native actions don't start a Logic Apps workflow, they carry no Logic Apps run charges.

A playbook is a logic app that starts with a Microsoft Sentinel trigger and then uses connectors: it can call a firewall, open a ServiceNow ticket, query a threat-intelligence service, branch on the result and write back to the incident. Each run is billed as a Logic Apps run.

The older method of attaching playbooks directly in an analytics rule's Automated response settings is deprecated (Microsoft stopped it in June 2023). Automation rules are the supported way to run playbooks automatically.

Every automation rule uses one of three triggers, and the trigger decides both when it runs and which actions it can take.

• When incident is created runs as soon as an incident exists. It is the trigger for first-touch triage such as assigning an owner, setting status to Active, raising severity or adding a checklist.
• When incident is updated runs when an existing incident changes: status, severity, owner, tags, tactics, alerts added, comments added and so on. It never fires for the creation event itself.
• When alert is created runs for alerts from Scheduled and NRT analytics rules and Microsoft security rules. Its only action is Run playbook; the owner, status, severity, tag and task actions apply to incidents.

Microsoft recommends incident-based automation in general. The main reason to use the alert trigger is an analytics rule that has incident creation turned off, for example when an external ticketing system should receive one ticket per alert. With no incidents, the incident triggers simply never fire.

The automation rule's trigger must match the playbook's Logic Apps trigger. An incident-trigger rule lists only incident-trigger playbooks, and an alert-trigger rule lists only alert-trigger playbooks. Playbooks built on the entity trigger never appear in an automation rule; they are for manual runs only (see the playbook trigger section).

Conditions decide which incidents a rule acts on; by default every condition must be true (AND), and the operator you choose decides whether you are testing the current value or a change. Conditions use incident properties such as analytics rule name, severity, status, tactics, tags, owner, entity values and custom details.

Current state vs a change

On the update trigger you get state-change operators in addition to the ordinary ones:

So a rule that should act once, at the moment an analyst moves an incident to Active, is an update rule with Status Changed to Active. Status Equals Active would also match every later edit of an incident that is already Active.

Updated by and self-triggering loops

The update trigger also offers Updated by, whose values distinguish who made the change: a user, an application, alert grouping, another automation rule or a playbook. Any change a playbook writes, including a comment, is an incident update. An update rule whose playbook writes back to the incident therefore re-triggers itself unless you add Updated by Does not equal Playbook (or exclude automation rules, as appropriate).

OR logic

Several values inside one condition are alternatives for that one property (severity is High or Medium). To accept either of two different properties in a single rule, add a Condition group (Or): each side is evaluated independently and one true side is enough. Rule order never changes how conditions combine.

Tags: Any individual tag vs Collection of all tags

The tag property can be tested per tag or as a set. With Any individual tag, a condition is true if at least one tag satisfies it. That is fine for positive tests, but a negative test misleads on multi-tag incidents: Any individual tag Does not contain Pentest is true for an incident tagged Pentest and Network, because Network doesn't contain Pentest. Collection of all tags evaluates the set as one unit, so Does not contain Pentest is false whenever any tag contains Pentest. Use the collection form for negative tag conditions.

Automation rules run one at a time, in ascending order number, in a separate queue per trigger, and each rule evaluates the incident as earlier rules left it. Several consequences follow:

• Sequential, never parallel. Rules on the same trigger run one after another; actions inside a rule run in the order listed. Rules with the same order number run in an undefined order, so give dependent rules distinct numbers.
• Later rules see earlier changes. If rule 1 lowers severity from Medium to Low, a later rule with a "Medium or higher" condition no longer matches. Conditions are checked against the current state when each rule runs, not a snapshot from creation.
• Create before update. A change made by a create-trigger rule is an incident update, but update-trigger rules for a just-created incident wait until every applicable create-trigger rule has finished. They don't interleave with the create queue.
• Playbook actions don't hold the rule indefinitely. If a playbook finishes in under two minutes, the rule continues shortly after it completes (up to about 10 seconds). If it runs longer, the rule moves to its next action two minutes after the playbook started; the playbook keeps running and is not cancelled. A long-running playbook followed by an action that depends on its result in the same rule can therefore lose the race, because that action may run before the playbook has finished. Put dependent steps inside the playbook, or trigger them from an update rule keyed to something the playbook writes (a tag, for example).

An automation rule can carry an expiration date, after which it stops running, and it can add incident tasks that give analysts a checklist on the incident page.

Time-limited suppression

For planned, time-boxed noise such as a penetration test or a maintenance window, create a rule that matches the affected incidents (by entity, analytics rule name or tag), sets status to Closed with a classification such as benign positive, and has an expiration date at the end of the window. The rule switches itself off without anyone remembering to delete it, and detection coverage stays on. Disabling the analytics rules instead would remove detection entirely and still need someone to re-enable them.

Incident tasks

Incident tasks standardise triage, investigation and remediation steps. An automation rule's Add task action adds a task (title and optional description) to every incident its conditions match; analysts tick tasks off on the incident page. Tags and custom details classify or surface data; they are not checklists, and workbooks visualise data rather than attaching trackable steps to incidents.

Tasks appear in the order they were created. Within one rule, that is the order of its actions; across rules, it is the rules' order numbers. Microsoft's guidance is to give rules that add tasks to all incidents a lower order number, so general triage tasks come first, followed by rules that add tasks for specific analytics rules. Moving tasks to an update rule makes them later still.

Automation rules can add tasks but have no action that completes one.

When a Microsoft Sentinel workspace is onboarded to the Microsoft Defender portal, incidents come from the Defender XDR correlation engine, and several automation rule behaviours change. Microsoft documents these differences:

• Avoid incident titles in conditions. The Defender engine correlates alerts and can rename incidents, so a Title contains condition silently stops matching. Use the Analytic rule name of a rule whose alerts are in the incident, and add tags if you need more precision.
• Incident provider is removed. Every incident's provider is Microsoft XDR, so the Incident provider condition no longer exists.
• No Description field. The SecurityIncident table loses the Description field, so conditions built on it stop working.
• The standard alert trigger acts only on Microsoft Sentinel alerts, not on Defender product alerts. Microsoft incident creation rules (which built Sentinel incidents from Microsoft product alerts) aren't supported in the Defender portal.
• Update batching. When an incident changes several times within about 5-10 minutes, Sentinel receives a single update carrying only the latest change. Update-trigger automations that rely on every intermediate state, such as ticket sync, can miss changes.
• Manual playbook runs on alerts and entities are not currently supported in the Defender portal; they remain an Azure portal capability.

Enhanced Alert Trigger

To automate at alert level across both Sentinel and Defender sources, the Defender portal provides the Enhanced Alert Trigger. It applies at tenant level to the workspaces you select, covers alerts from Microsoft Sentinel, Microsoft Defender and XDR sources, supports conditions such as severity, and its action runs playbooks created with the playbook generator. It doesn't use automation rule order numbers or expiration dates.

A Sentinel playbook starts with one of three Microsoft Sentinel connector triggers, incident, alert or entity, and that choice fixes what data it receives and how it can be started.

A playbook missing from an automation rule's drop-down usually has the wrong trigger; rebuild it on the matching trigger. If a playbook with an entity trigger needs to run automatically, rebuild it on the incident trigger and extract the entities with an Entities action.

Key connector actions

• Update incident changes status, owner, tags, severity, title or description in one action.
• Add comment to incident appends text; it changes no incident property.
• Add task to incident and Mark task as completed manage incident tasks.
• Most incident actions need the Incident ARM ID. An incident-trigger playbook already has it. An alert-trigger playbook first calls Alert - Get Incident to retrieve the parent incident and its ARM ID. Get Incident is for workflows started from a non-Sentinel trigger and itself takes the ARM ID as input.

Working with entities

The incident trigger supplies entities as an array of JSON objects. The Entities - Get <type> actions filter that array to one type and parse its type-specific fields, ready for a For each loop, but they exist only for IPs, Hosts, Accounts, URLs and FileHashes. For any other entity type, such as a mail message or a registry key, use the Logic Apps built-in Filter array action on the entity kind, then Parse JSON to expose its fields. Filtering without parsing leaves the type-specific fields unavailable as dynamic content.

Two separate permission questions apply to playbooks: whether Microsoft Sentinel itself may trigger them, and what each person may do with them.

Sentinel's permission to run playbooks

Automation rules run playbooks through a Microsoft Sentinel service account (the Azure Security Insights app), not as the user who built the rule. That account needs the Microsoft Sentinel Automation Contributor role on the resource group that holds the playbooks. You grant it in Manage playbook permissions (also under Settings) by selecting the resource group; once granted, any automation rule can run any playbook in that group. Granting it creates a role assignment, so it needs Owner or User Access Administrator on the resource group; if you lack them, the resource group appears greyed out in that dialog.

The symptom tells you which problem you have: a playbook that is listed but greyed out in the Run playbook drop-down means Sentinel lacks permission on its resource group; a playbook that is not listed at all has the wrong trigger. Your own roles and the playbook's location don't change either case.

Multitenant (MSSP) case: normally the permission is granted in the playbook's own tenant. When an automation rule is created from a provider tenant through Azure Lighthouse but calls a playbook in the customer tenant, both tenants need it: Manage playbook permissions in the customer tenant, and in the Lighthouse delegation an authorization giving the Azure Security Insights app (by its object ID) the Microsoft Sentinel Automation Contributor role on the playbook's resource group.

User roles

How the playbook authenticates to Sentinel

Once a playbook runs, its Microsoft Sentinel connector connection needs its own identity to read or change incidents. Three options exist:

• Managed identity (recommended): no secret to store or rotate. Enable the logic app's managed identity (system-assigned is tied to the logic app and adds no identity to manage), assign it Microsoft Sentinel Responder on the workspace if it updates incidents or watchlists, or Microsoft Sentinel Reader if it only reads, then create the connection with Connect with managed identity. Contributor also works but over-grants.
• Service principal: a registered Entra app with a client secret or certificate to store and rotate.
• Microsoft Entra user: a person's sign-in; it breaks when that account changes and runs actions as that person.

The playbook identity's role and the service account's Automation Contributor role solve different problems: one lets the playbook change incidents, the other lets Sentinel start the playbook.

Microsoft Sentinel playbooks can run on either Consumption (multitenant) or Standard (single-tenant) logic apps, with three Standard-specific limits.

The private-endpoint case has a distinctive symptom: without the access restriction policy, Standard workflows still appear and can be selected in automation rules, but every run fails. When a team wants a template with the fewest build steps, the template creates a Consumption logic app.

Automation rule outcomes are logged in the SentinelHealth table once health monitoring is enabled, while what happened inside each playbook run comes from Logic Apps diagnostic logs in AzureDiagnostics.

Each automation rule run whose conditions are met writes a SentinelHealth record with OperationName == "Automation rule run" and one of three statuses:

• Success: every action was triggered.
• Partial success: the rule ran and at least one action succeeded, but some failed.
• Failure: no action ran, for example because conditions failed to evaluate or the first action failed.

Manual playbook triggering is logged as Playbook was triggered, with Success or Failure only.

SentinelHealth
| where TimeGenerated > ago(1d)
| where OperationName == "Automation rule run"
| where Status == "Partial success"

Success for a rule run means its playbooks were triggered, not that they finished. To see whether a playbook completed and which action failed, send each logic app's diagnostic logs to the Sentinel workspace; workflow and action start/end events land in AzureDiagnostics. The rule-run record lists the playbooks it triggered with their run IDs, so you expand that list and join to AzureDiagnostics on the run ID. The Automation health workbook does this correlation for you. Sentinel's auditing feature records changes to Sentinel resources, not playbook run outcomes.