This chapter focuses on alert enrichment using automation rules in Microsoft Sentinel, a key topic for the SC-200 exam. Automation rules allow you to automatically enrich, triage, and manage alerts and incidents without manual intervention. Understanding how to create, order, and troubleshoot automation rules is critical because approximately 10-15% of SC-200 questions involve automation rules or related playbooks. You will learn the internal mechanism, step-by-step configuration, and common exam traps to ensure you can answer any question confidently.
Jump to a section
Imagine a large corporate mailroom where every incoming envelope is an alert. The mailroom receives hundreds of envelopes per minute, each with different urgency, sender, and content. A junior clerk initially opens each envelope and assigns a priority tag based on the sender's department (e.g., 'CEO' gets highest priority, 'IT' gets medium). This is like the analytics rule creating an alert with a basic severity. However, the mailroom also has a senior supervisor who applies additional enrichment: for any envelope from 'Legal' marked 'Confidential', the supervisor adds a 'Confidential' stamp and routes it to a secure bin. For any envelope with 'Invoice' in the subject, the supervisor attaches a 'Payment Due' note and forwards it to Accounts. These enrichment actions happen automatically based on predefined rules, not manually. Similarly, in Microsoft Sentinel, after an analytics rule generates an alert, automation rules can run immediately to enrich the alert with additional information (like adding tags, changing severity, or assigning it to a specific analyst) before it reaches the incident queue. The automation rule is like the supervisor's rule book: it matches conditions (e.g., alert contains 'Confidential') and executes actions (e.g., add tag 'Legal-HighPriority'). This pre-processing ensures that when the incident is created, it already carries context that speeds up triage.
What Are Automation Rules and Why Do They Exist?
Automation rules in Microsoft Sentinel are a lightweight, built-in mechanism to automate incident handling and alert enrichment. They were introduced to reduce the need for complex playbooks for simple, recurring tasks. An automation rule consists of three parts: conditions (when to run), actions (what to do), and an order (priority). They run at two trigger points: when an alert is created (before incident creation) and when an incident is created or updated (after incident creation). The key benefit is that they execute immediately, without the latency of invoking a playbook, and they can modify the alert or incident in-place.
Internal Mechanism: Step-by-Step Flow
1. Alert Generation: An analytics rule (e.g., Scheduled, NRT, or Microsoft Security) triggers and produces an alert. This alert has a set of properties: severity, status, tactics, entities, and custom details. 2. Pre-Incident Automation Rule Check: Before the alert is grouped into an incident, Sentinel checks if any automation rules have the trigger condition 'When alert is created'. These rules run in order of their 'Order' property (ascending integer, lower number runs first). If the alert matches the rule's conditions (e.g., 'Alert Severity equals High' AND 'Alert Product Name contains Azure'), the rule's actions execute. 3. Actions Execution: Actions can include: - Add tags: e.g., 'Priority-High', 'RequiresReview' - Change severity: e.g., from Medium to High - Assign to owner: e.g., to a specific analyst or group - Run a playbook: but this is synchronous and adds latency (playbooks are covered in a separate objective) - Suppress: close the alert without creating an incident (if the rule is set to suppress) 4. Incident Creation: After pre-incident automation runs, the alert is grouped into an incident based on the analytics rule's grouping settings. The incident inherits the enriched properties from the alert. 5. Post-Incident Automation Rule Check: When an incident is created or updated, Sentinel checks automation rules with trigger 'When incident is created' or 'When incident is updated'. These rules can perform additional actions like:
- Changing incident status (e.g., to Active) - Adding comments - Assigning to a specific analyst - Running a playbook for deeper investigation
Key Components, Values, Defaults, and Timers
- Order: An integer from 0 to 999. Default is 0. Lower numbers run first. If two rules have the same order, the order of execution is non-deterministic. It is critical to set unique orders. - Triggers: - 'When alert is created' – runs before incident creation. Actions can modify the alert. - 'When incident is created' – runs after incident creation. - 'When incident is updated' – runs on any status change or attribute update. - Conditions: Up to 5 conditions per rule. Conditions can be based on:
- Alert properties: Severity, Status, Product Name, Product Component Name, Provider Name, Analytic Rule Name, Tactics, Techniques, Alert Display Name, Description - Incident properties: same as above plus Incident Status, Owner, Tags, etc. - Conditions can use operators: Equals, Not Equals, Contains, Not Contains, Starts With, Ends With, and for arrays (like Tactics) uses 'Contains' meaning at least one element matches. - Actions:
- Change severity (options: Informational, Low, Medium, High, Critical) - Change status (New, Active, Closed) - Assign owner (user principal name or group) - Add tags (up to 10 tags per rule, each tag up to 256 characters) - Run playbook (only from post-incident triggers; pre-incident cannot run playbooks because incident doesn't exist yet) - Suppress alert (only available in pre-incident trigger; closes the alert without creating an incident) - Expiration: Automation rules do not expire. They remain active until deleted or disabled. - Limits:
Maximum 1,000 automation rules per workspace.
Maximum 5 conditions per rule.
Maximum 10 tags per action.
Playbook actions are limited by Logic Apps limits (e.g., 2-minute timeout for synchronous calls).
Configuration and Verification
To create an automation rule in the Azure portal: 1. Navigate to Microsoft Sentinel > Automation > Create > Add new rule. 2. Name the rule (unique within workspace). 3. Select trigger: 'When alert is created' or 'When incident is created/updated'. 4. Set Order (e.g., 10). 5. Add conditions: e.g., 'Alert Severity equals High' AND 'Alert Product Name contains Azure Defender'. 6. Add actions: e.g., 'Change severity to Critical', 'Add tag: AzureDefender-High'. 7. Review and create.
To verify using Azure CLI:
az sentinel automation-rule list --resource-group <rg> --workspace-name <workspace>
az sentinel automation-rule show --resource-group <rg> --workspace-name <workspace> --automation-rule-name <rule-name>To test, generate an alert that matches conditions and observe the alert/incident properties in the Sentinel Logs or Incident queue.
Interaction with Related Technologies
Analytics Rules: Automation rules depend on analytics rules to produce alerts. Without analytics rules, automation rules have no alerts to act on.
Incidents: Automation rules modify incidents. Post-incident rules can change incident status, owner, etc.
Playbooks: Automation rules can trigger playbooks for complex automation. However, playbooks run asynchronously and can have delays. Automation rules are synchronous and immediate.
Workbooks and Hunting: Automation rules do not directly interact with workbooks or hunting queries.
UEBA: Automation rules can use UEBA entities if the alert contains enriched entities.
Important Exam Details
Order of execution: The SC-200 exam often tests that you understand the order: pre-incident rules run first (on alert creation), then incident creation, then incident update. Within each trigger, rules run by Order number ascending.
Cannot run playbooks from pre-incident trigger: This is a common exam trap. The exam may ask: 'You want to run a playbook as soon as an alert is created. What should you do?' The correct answer is to use a post-incident trigger (when incident is created) because the playbook action is only available for incident triggers.
Suppression action: Only available in pre-incident trigger. If you want to close an alert without creating an incident, you must use 'When alert is created' trigger and add the 'Suppress' action.
Tag limits: Maximum 10 tags per action. The exam may ask about limits.
Condition operators: 'Contains' for text fields means substring match; for array fields (like Tactics) it means the array contains at least one matching element. 'Equals' requires exact match.
Automation rules vs. Playbooks: Automation rules are for simple, conditional actions; playbooks are for complex, multi-step workflows. The exam may ask which to use in a given scenario.
Troubleshooting
If an automation rule does not execute as expected:
Check the rule's trigger: is it pre-incident or post-incident? If the rule is set to 'When incident is created' but the alert is not creating an incident (e.g., due to grouping settings), the rule never runs.
Check the order: a higher-order rule might override actions? No, all matching rules run in order. But if two rules change severity, the last one to run wins.
Check conditions: ensure the alert/incident properties match exactly. Use KQL to inspect the alert schema.
Check permissions: the automation rule runs in the context of the Sentinel service principal. Ensure it has necessary permissions (e.g., to run playbooks, the rule needs Logic App Contributor on the playbook).
Performance and Scale
Automation rules are designed for high throughput. They can process thousands of alerts per second. However, if a rule runs a playbook that takes a long time, it may delay incident creation. Best practice is to use pre-incident rules for lightweight enrichment (tags, severity changes) and post-incident rules for playbooks.
Summary of Default Values
Order: 0
Conditions: none (rule runs on all alerts/incidents)
Actions: none
Trigger: When incident is created (default in portal wizard)
Status: Enabled
Exam Scenario Example
You have a scheduled analytics rule that detects failed logins. You want to automatically tag all alerts with severity High as 'Critical-FailedLogin' and assign them to the SOC team. Which automation rule configuration should you use? - Trigger: When alert is created (so tags are added before incident creation) - Conditions: Alert Severity equals High AND Alert Analytic Rule Name equals 'Failed Login Detection' - Actions: Add tag 'Critical-FailedLogin', Assign owner 'soc-team@contoso.com'
Note: Assign owner is only available in post-incident triggers? Actually, assign owner is available in both pre-incident and post-incident triggers? Wait: The assign owner action is available only in post-incident triggers because the incident owner concept doesn't exist for alerts. Alerts do not have an owner; incidents do. So if you want to assign an owner, you must use a post-incident trigger. This is a critical exam detail. The above scenario would require two rules: one pre-incident to add tag, and one post-incident to assign owner. Or you can combine in a single post-incident rule if the trigger is 'When incident is created' and conditions match the alert properties inherited by the incident.
Let's clarify: Pre-incident rules can change severity, add tags, and suppress. They cannot assign owner, change status, or run playbooks. Post-incident rules can change severity, add tags, assign owner, change status, add comments, and run playbooks. So if you need to assign owner, you must use a post-incident trigger.
Conclusion
Automation rules are a powerful, efficient way to enrich alerts and incidents in Microsoft Sentinel. They are a key differentiator for SOC efficiency. For the SC-200 exam, focus on triggers, actions, order, and limitations. Practice creating rules in a demo environment to solidify understanding.
Navigate to Automation Blade
In the Azure portal, open Microsoft Sentinel and select your workspace. In the left menu, under Configuration, click 'Automation'. This opens the Automation blade, which lists all existing automation rules and playbooks. From here, you can create new rules or edit existing ones. The blade also shows the order of rules and their status (Enabled/Disabled). This is the starting point for any automation rule configuration.
Create New Rule and Set Trigger
Click 'Create' and select 'Add new rule'. A wizard appears. First, provide a descriptive name (e.g., 'Tag High Severity Alerts'). Then choose the trigger: 'When alert is created' for pre-incident enrichment, or 'When incident is created' or 'When incident is updated' for post-incident actions. The trigger determines what actions are available. For example, 'When alert is created' allows suppression but not assignment of owner. This choice is critical and often tested.
Set Order and Conditions
Specify the order (integer) to define the execution sequence among rules with the same trigger. Lower numbers run first. If two rules have the same order, the order is non-deterministic. Then add conditions: up to 5 conditions using alert or incident properties such as Severity, Status, Product Name, Analytic Rule Name, etc. Conditions use operators like Equals, Contains, Starts With. For array fields like Tactics, 'Contains' checks if any element matches. Conditions are evaluated in sequence; all must be true for the rule to run.
Configure Actions
Add one or more actions. Available actions depend on the trigger. For pre-incident: Change severity, Add tags, Suppress alert (closes alert without incident). For post-incident: Change severity, Change status, Assign owner, Add tags, Add comments, Run playbook. You can add multiple actions; they execute in the order listed. For example, you can change severity to Critical and then add a tag 'Critical'. Note that tags are additive; existing tags are preserved.
Review and Create Rule
Review the configuration summary. Ensure conditions and actions are correct. Click 'Create'. The rule appears in the Automation list with its order and status. It is enabled by default. To test, generate a matching alert (e.g., from a scheduled query) and observe the alert or incident properties. You can also edit or disable the rule later. Remember that automation rules are evaluated in order; if a later rule conflicts with an earlier one, the last action wins.
Enterprise Scenario 1: SOC Triage Automation
A large financial institution receives over 10,000 alerts per day from various security products (Azure Defender, Microsoft 365 Defender, custom analytics). The SOC team wants to automatically tag alerts from critical systems (e.g., domain controllers, payment gateways) with 'Critical-Asset' and escalate severity to High. They create a pre-incident automation rule with condition: 'Alert Product Name contains Azure Defender' AND 'Alert Severity equals Medium' AND 'Alert Display Name contains Domain Controller'. The rule adds tag 'Critical-Asset' and changes severity to High. This enrichment ensures that when incidents are created, they already have context for the triage analyst. The rule runs in order 10, allowing other rules to run later if needed. Performance is excellent: enrichment adds less than 50ms latency per alert.
Enterprise Scenario 2: Compliance-Driven Assignment
A healthcare organization must ensure that all incidents involving patient data (PHI) are assigned to a senior analyst within 15 minutes. They use a post-incident automation rule triggered on incident creation. Condition: 'Alert Product Name equals Microsoft 365 Defender' AND 'Alert Tactics contains DataExfiltration'. The rule assigns owner to 'soc-senior@hospital.com', changes status to 'Active', and adds comment 'PHI incident - escalate if not resolved in 1 hour'. This rule runs at order 5, before other assignment rules. One common misconfiguration is forgetting that the 'Assign owner' action requires the user to be a valid Azure AD user with Sentinel permissions. If the user is not found, the action fails silently, and the incident remains unassigned. Monitoring automation rule execution via the Sentinel Audit Logs is essential.
Scenario 3: Alert Suppression for False Positives
A technology company has a scheduled rule that detects failed logins from known bad IPs but also generates false positives from internal vulnerability scanners. They create a pre-incident automation rule that suppresses alerts where 'Alert Display Name contains Vulnerability Scanner' AND 'Alert Severity equals Informational'. The rule adds tag 'Suppressed-FalsePositive' and uses the 'Suppress alert' action. This prevents incident creation for these alerts, reducing noise by 20%. A pitfall: if the suppression condition is too broad, legitimate alerts may be suppressed. Regular review of suppressed alerts via Sentinel Logs (Alert table with Status='Closed') is recommended.
SC-200 Exam Focus on Automation Rules
The SC-200 exam objective 2.5 specifically covers 'Create and manage automation rules'. Expect 2-4 questions that test your understanding of triggers, actions, order, and limitations. The most commonly tested points are:
Trigger Differentiation: You must know which actions are available for each trigger. The exam often asks: 'You need to automatically assign an incident to a specific analyst when an alert is created. What should you do?' The trap is that assignment is only available in post-incident triggers, so the correct answer is to create an automation rule with trigger 'When incident is created' (not 'When alert is created'). Many candidates incorrectly choose the pre-incident trigger.
Order of Execution: Questions may present a scenario with multiple automation rules and ask which action takes effect. Remember: rules run in ascending order of the 'Order' property. If two rules change the same property (e.g., severity), the last one to run wins. The exam may ask: 'Rule A (order 10) changes severity to High; Rule B (order 20) changes severity to Medium. What is the final severity?' Answer: Medium.
Suppression Action: The suppression action is only available in the pre-incident trigger. A question might say: 'You want to close an alert without creating an incident. Which automation rule trigger should you use?' Answer: When alert is created. The distractor is 'When incident is created' – but that trigger runs after the incident exists, so you cannot prevent incident creation.
Condition Operators: The exam tests the difference between 'Equals' and 'Contains'. For example, 'Alert Display Name contains 'malware'' will match 'Malware detected' but not 'Malicious activity'. 'Equals' requires exact match. Also, for array fields like Tactics, 'Contains' means the array includes at least one matching element. A question might ask: 'Which condition would match an alert with Tactics: [InitialAccess, Execution]?' The condition 'Tactics Contains InitialAccess' would match.
Limits and Quotas: The exam may test the maximum number of conditions per rule (5), maximum tags per action (10), and maximum automation rules per workspace (1,000). These numbers appear verbatim.
Playbook Integration: Automation rules can run playbooks only from post-incident triggers. The exam might ask: 'You need to run a playbook that sends an email when an incident is created. How do you achieve this?' Answer: Create an automation rule with trigger 'When incident is created' and add action 'Run playbook'. The distractor is using a pre-incident trigger.
Common Wrong Answers:
Choosing 'When alert is created' for actions that require an incident (assign owner, change status, run playbook).
Assuming automation rules can run playbooks synchronously (they run asynchronously, but the trigger is synchronous).
Thinking that conditions can use logical OR (they are AND only; to achieve OR, you need multiple rules).
Forgetting that tags are additive; if you want to replace tags, you must clear them first (not possible via automation rules; you need a playbook).
Edge Cases:
If an automation rule fails (e.g., playbook not found), the rule is skipped and execution continues to the next rule. No rollback occurs.
Automation rules do not support conditions based on custom entities; only built-in properties.
The 'Assign owner' action requires the user or group to have Sentinel Reader role or higher; otherwise, assignment fails.
How to Eliminate Wrong Answers: Use the trigger-action compatibility matrix. If the question involves assigning owner, changing status, or running a playbook, eliminate any answer that uses 'When alert is created'. If the question involves suppressing an alert, eliminate answers that use 'When incident is created'. If the question involves multiple rules, consider the order.
Specific Terms: The exam uses exact property names: 'Alert Severity', 'Alert Status', 'Analytic Rule Name', 'Product Name', 'Tactics', 'Techniques'. Know that 'Tactics' is an array of MITRE ATT&CK tactics. 'Product Name' refers to the source product (e.g., 'Azure Sentinel', 'Azure Defender', 'Microsoft 365 Defender').
Automation rules have two trigger types: 'When alert is created' (pre-incident) and 'When incident is created/updated' (post-incident).
Pre-incident actions: Change severity, Add tags, Suppress alert. Post-incident actions: all pre-incident plus Change status, Assign owner, Add comments, Run playbook.
Rules execute in ascending order of the 'Order' property (integer). Lower numbers run first.
Maximum 5 conditions per rule, all combined with AND. For OR, create multiple rules.
Maximum 10 tags per action, 1,000 automation rules per workspace.
The 'Suppress alert' action is only available in the 'When alert is created' trigger.
The 'Assign owner' and 'Run playbook' actions are only available in post-incident triggers.
Automation rules do not support custom properties or entities; only built-in alert/incident properties.
If a rule fails (e.g., playbook not found), execution continues to the next rule; no rollback.
Automation rules are evaluated for every alert/incident; they do not have a separate schedule.
These come up on the exam all the time. Here's how to tell them apart.
Automation Rules
Lightweight, built-in, no additional cost beyond Sentinel.
Runs synchronously with alert/incident creation; low latency (<50ms).
Limited to simple actions: change severity, add tags, assign owner, change status, suppress, run playbook (only post-incident).
Maximum 5 conditions per rule; no branching or loops.
Ideal for common, repetitive enrichment tasks like tagging and severity changes.
Playbooks
Azure Logic Apps-based, incurs consumption cost per execution.
Runs asynchronously; can have seconds to minutes of latency.
Supports complex workflows: multiple steps, conditions, loops, integrations with external systems (e.g., email, ticketing).
Unlimited conditions via Logic Apps designer; can include custom code.
Ideal for complex investigations, approval workflows, and integrations with third-party tools.
Mistake
Automation rules can run playbooks from the 'When alert is created' trigger.
Correct
The 'Run playbook' action is only available for post-incident triggers ('When incident is created' or 'When incident is updated'). Pre-incident rules cannot run playbooks because the incident does not exist yet, and playbooks require an incident context.
Mistake
If two automation rules have the same order, both run in a predictable sequence.
Correct
When two rules have the same order value, the order of execution is non-deterministic. Microsoft does not guarantee which runs first. Best practice is to assign unique order numbers to avoid ambiguity.
Mistake
The 'Suppress alert' action is available for both pre-incident and post-incident triggers.
Correct
The 'Suppress alert' action is only available in the 'When alert is created' trigger. Once an incident is created, you cannot suppress the alert retroactively; you would need to close the incident instead.
Mistake
Automation rules can assign an owner to an alert.
Correct
Alerts do not have an owner property; only incidents have an owner. Therefore, the 'Assign owner' action is only available for post-incident triggers. To assign an owner, you must use a rule triggered on incident creation or update.
Mistake
Conditions in automation rules support logical OR between different criteria.
Correct
All conditions within a single automation rule are combined with logical AND. To achieve OR logic, you must create multiple automation rules, each with its own set of conditions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, automation rules cannot create or close incidents without an alert. The 'Suppress alert' action in a pre-incident rule prevents an incident from being created at all. To close an incident after creation, you need a post-incident rule that changes the status to 'Closed'. However, the incident still exists in the system. If you want to completely avoid incident creation, use the 'Suppress alert' action on the 'When alert is created' trigger.
The condition evaluates to false, so the rule does not run. For example, if you use 'Alert Product Name equals Azure Defender' but the alert is from a custom analytics rule without that property, the condition fails. There is no error; the rule is simply skipped. Always verify that the property exists in the alert schema using a sample alert.
Set the 'Order' property of the first rule to a lower number than the second rule. For example, set Rule A order=10 and Rule B order=20. Rules with lower order numbers execute first. If they have the same order, the order is non-deterministic, so always use unique values.
No, once an alert is grouped into an incident, the alert is immutable. Automation rules that run on incident creation or update operate on the incident, not the individual alerts. To modify an alert before it becomes part of an incident, use a pre-incident rule ('When alert is created').
You can create a test analytics rule that generates alerts on a schedule (e.g., every hour) with a simple query like 'Heartbeat | where TimeGenerated > ago(5m)'. Then create an automation rule that tags those alerts. Alternatively, you can use the Sentinel 'Simulate' feature (if available) or manually trigger a playbook via the 'Run' button, but that only tests playbooks, not automation rules. The best approach is to use a test workspace.
No, automation rules cannot add custom details (key-value pairs) to alerts. They can only add tags (which are strings) and change severity, status, owner, or comments. Custom details must be added at the analytics rule level via the 'Custom details' configuration.
You need at least 'Microsoft Sentinel Contributor' role on the workspace to create, edit, or delete automation rules. To run a playbook from an automation rule, you also need 'Logic App Contributor' on the playbook resource. The automation rule itself runs under the Sentinel service principal, so no additional permissions are needed for basic actions.
You've just covered Alert Enrichment with Automation Rules — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?