Forum Discussion
Sentinel SOAR migration to Unified portal: what broke? anyone evaluated the AI playbook generator?
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.