Concept and mechanism
Detection becomes response only when suitable actions, owners, and permissions exist. Automation rules have triggers, conditions, and execution order that should reflect actual dependencies. A playbook uses Logic Apps to coordinate actions; editing the rule and allowing the service to execute it are distinct authorizations. Sentinel needs appropriate access to the playbook resource group. Internal actions also use identities and connections with their own scopes. Moving resources between groups can change effective access. Do not resolve a service failure by indiscriminately assigning global roles to analysts: identify the denied principal and operation.
Guided application
For custom detections, retain identifiers and times relevant to alert context. Current documentation recommends these columns and describes using lookback boundaries when Timestamp and TimeGenerated are not projected; do not teach an old blanket rule that their absence always prevents creation. Also confirm the device scope the author can manage. A working query does not grant rights to edit a global rule. When a template is updated, compare the new version with customizations and validate changes before applying them. For a fictional handover, test automation success and failure and define an authorized manual response for unavailable periods.
The rule triggers, but a playbook moved to another group is denied: investigate execution permissions and scopes.
Common pitfalls
Author as executor; valid query as global permission; updated template as updated rule; automation without fallback.
Related topics: Triage and endpoint response · Identity, content, and handover
Connect each trigger to verifiable actions and identities with minimum necessary access.
Reference: Response playbooks · SC-200 objectives effective 2026-07-28; Microsoft product documentation reviewed 2026-10-01; 2026-10-21 English update compared separately