Sentinel playbooks after the Defender portal move

Microsoft supports Sentinel only in the Defender portal after 2027-03-31, and its own docs list automation changes: batched incident updates, delays before rules run, and manual playbook runs not yet supported. This guide turns those facts into a test plan you can run before the deadline.

The deadline is 147 days from today

Microsoft's playbook documentation states that after 2027-03-31 Microsoft Sentinel is supported only in the Microsoft Defender portal, and Azure portal customers are redirected (Microsoft, Automate threat response with playbooks) (read 2026-11-03). Counting from 2026-11-04, that is 147 days. The page is dated 2026-06-12.

Treat that as a project with a hard date, not a portal preference. Every automation rule and every playbook you run today was built and tested in the Azure portal's incident model. The Defender portal handles incidents differently, and Microsoft says so.

Microsoft documents three behaviours that change your timing

The automation page, updated 2026-06-28, lists differences in the Defender portal. Three of them touch SOC response time directly (Microsoft Sentinel automation in the Defender portal) (read 2026-11-03):

Incident updates are batched. Updates arrive in batches of 5 to 10 minutes.
Rules wait. It can take up to 10 minutes before automation rules run.
Manual runs are missing. Manually running a playbook is not yet supported in Defender.

None of these breaks a playbook. All of them break an assumption. If your containment playbook for a high-severity identity alert assumes the rule fires within seconds, a ten-minute wait is a different control. If analysts click "run playbook" on an incident to enrich it, that path is not available yet.

Write down every playbook where time matters, and mark which ones start from an automation rule and which from a manual run. The manual-run list is the one that needs a workaround before March.

Playbooks are Logic Apps, and that part stays

A Sentinel playbook is an Azure Logic Apps workflow, either Consumption or Standard. A playbook template is an ARM template that holds a Logic Apps workflow and its API connections (Microsoft, Automate threat response with playbooks) (read 2026-11-03). The Logic Apps layer does not change with the portal. The designer, the connectors and Azure Functions for code stay where they are.

Automation rules are the layer to watch. They trigger on incident created, incident updated or alert created. Built-in actions cover tasks, status, severity, owner, tags and closing with a reason, and a rule can call a playbook. Rules run in order by number, and they can be exported as ARM JSON for CI/CD (Microsoft, Automation rules) (read 2026-11-03). Only incident-trigger playbooks run from incident-trigger rules, and only alert-trigger playbooks from alert-trigger rules. Running a playbook from a rule needs the Microsoft Sentinel Automation Contributor role on the playbook's resource group.

Because rules run in order and the Defender portal changes when they fire, rule order is where a surprise hides. Two rules that never collided in Azure may now run against an incident that another rule just changed.

Export is ARM JSON, which keeps you inside Azure

The Logic Apps code view exposes the ARM JSON. Microsoft advises removing tenant and subscription details, and a script in the Azure-Sentinel GitHub repository, Playbook_ARM_Template_Generator.ps1, exports a sanitized template (Microsoft Sentinel playbook creation guidance) (read 2026-11-03, search summary). Templates deploy to Azure from the Azure-Sentinel GitHub playbooks folder.

That keeps a move to another Azure tenant simple. A move to another vendor is different. No importer from another SOAR is documented either. If you plan to leave Sentinel automation for a SOAR, you rebuild.

Incoming migrations have a map, not a converter

If you are moving into Sentinel from Splunk SOAR or QRadar SOAR, Microsoft publishes a concept map to automation rules and Logic Apps, updated 2026-08-12. It maps Splunk prompts to a Send approval email step and Splunk containers and cases to incidents and cases. The page names no converter tool, and it advises human input on high-impact automations (Microsoft Splunk SOAR migration guide) (read 2026-11-03).

Approval is built by the author here, not a gate the product enforces. If your current SOAR holds approvals as a first-class step, rebuild each one on purpose.

Cost shows up in a different bill

Playbooks add Azure Logic Apps charges to Sentinel charges. Microsoft's pricing page lists analytics tier and data lake tier pricing by volume, and says playbooks add Logic Apps charges (Microsoft Sentinel pricing) (read 2026-11-03). Our scoring pass did not read Logic Apps billing, so we scored automation pricing 4.0 and flagged it for a re-read. If you run thousands of playbook executions a day, price them before you commit.

On the nine-criterion rubric Sentinel scores 6.21, with authoring at 8.5 and documented AI features at 4.0 because the pages read were silent on them. Those are scores on pages, and Security Copilot was not read.

Ownership notes for third-party tools

ServiceNow says Sentinel ingestion and sync continue to work in the Defender portal (ServiceNow Q1 2026 SecOps release notes) (read 2026-11-03). If you ticket from Sentinel into ServiceNow, test that sync early.

Checklist for the Defender portal move

Put 2027-03-31 on the plan and work back from it.
List every automation rule with its trigger, order number and playbook.
List every playbook that analysts run manually on an incident.
Measure the current time from incident creation to rule run, and compare in Defender.
Re-test time-sensitive playbooks with a 10 minute delay assumed.
Check rule order for collisions on incident updates.
Confirm the Automation Contributor role on each playbook's resource group.
Export each playbook as an ARM template and store it in source control.
Test ticket sync to any external system that reads Sentinel incidents.
Price Logic Apps runs separately from Sentinel ingestion.