Forum Discussion
Sentinel SOAR migration to Unified portal: what broke? anyone evaluated the AI playbook generator?
I want to open a conversation specifically focused on the automation and SOAR side of the migration, because this is the area where problems most commonly surface after onboarding rather than during it.
A quick orientation: the Unified portal introduces a specific constraint that catches teams by surprise. Alert-triggered automation for alerts created by Microsoft Defender XDR is not available in the Defender portal. The main use case for alert-triggered automation in this context is responding to alerts from analytics rules where incident creation is disabled. If you had alert-triggered playbooks firing on Defender XDR signals, those need to be re-evaluated against the incident trigger model. This is documented by Microsoft, but it is easy to miss in the volume of migration guidance.
The automation failure mode I have seen most consistently: automation rules built around incident title conditions. The Defender XDR correlation engine assigns its own incident names, so any condition keyed to "if incident title contains X" stops matching without throwing an error. The rule is still active, the automation is still enabled, and everything looks fine until someone notices a class of enrichment or response has gone quiet. Microsoft's recommendation is to use Analytic rule name as the condition instead.
There is also a firm near-term deadline separate from the March 2027 portal retirement: queries and automation need to be updated by July 1, 2026 for standardised account entity naming. The Name field will consistently hold only the UPN prefix from that date. Any automation comparing AccountName against a full UPN will break.
A few specific questions for practitioners:
- When you onboarded or reviewed your automation post-onboarding, what broke silently versus what produced a visible error? Silent failures are the dangerous ones and sharing specific patterns would be genuinely useful for the community.
- Has anyone evaluated the new AI playbook generator in the Defender portal? It requires Security Copilot with SCUs available and generates Python-based automation coauthored with Cline in an embedded VS Code environment. Interested in real-world comparisons against existing Logic Apps workflows for the same use case.
- For those who have migrated alert-triggered playbooks to automation rule invocation: did you find edge cases in the migration, particularly around playbooks used by multiple analytics rules simultaneously?
Writing this up as Part 4 of the migration series. Sharing the article link once it is live for anyone who wants the full detail.
1 Reply
- AndrewBlumhardt
Microsoft
Anthony, I think part of what we are seeing here is the result of a direction shift that has been happening for several years now away from alert-based automation and more toward incident-based orchestration. Even before the Unified portal migration, most newer Sentinel workflows were already assuming the incident was the primary operational object rather than the alert itself.
From a workflow perspective, I honestly do not think incident-based automation is that limiting. It is already very common in Sentinel playbooks to gather additional context after the incident trigger fires anyway. If someone still needs to process alerts individually, you can enumerate the related alerts after the incident trigger inside the workflow itself.
The bigger edge case is analytics rules generating alerts without incidents. Originally, that was more useful because Sentinel’s earlier correlation capabilities were not nearly as strong, so some customers built their own external correlation logic around alerts. In my experience, this is rarely used. But Defender XDR’s native correlation is much stronger now, which really reduces the need for that design pattern in most environments.
I do agree that customers with a large number of playbooks, regardless of whether they are alert-based or incident-based, are going to need to test their playbook triggers and operations carefully after migration. That is just good practice anytime you are moving to a new operational model or portal experience.
I also would avoid highly specific incident-title matching wherever possible. Use broader automation conditions to invoke the workflow, then handle the more granular logic inside the playbook itself where you have better context and control.
I have not taken a close look at the AI playbook generator yet, though I was surprised to hear the dependency on Security Copilot and SCUs. At this point, GitHub Copilot, Claude, and similar tools already do a surprisingly good job generating Logic Apps workflows, ARM templates, and even Python-based Azure Functions. I think it is an interesting option for Security CP users but not the only way to vibe code a workflow.
Honestly, Azure Functions are much easier to approach now because AI tooling removes a lot of the traditional coding barrier. A few years ago, building Python-based SOAR workflows required much deeper developer experience. Today, someone with strong operational knowledge can realistically build fairly advanced workflows with AI assistance.
