Hey @collin_peel ,

What is the source for your detections? Playbooks are triggered on the Alerts within cases. It's possible to create cases via API, but we have other ingestion mechanisms that can help to solve this use case like Connectors and Webhooks.

Playbooks run against Alerts, so if your detection comes to SecOps as 1 Alert per finding, then everything is ok.
Alerts are grouped into Cases simply to help the analyst focus on 'a story' of related things, it does not limit or change how an Alert will process itself. 

However if you have a situation where 5 hosts/detections in one Alert then:
i) I firstly recommend you engineer the detection to not group, it will help with other elements and features of the platform as you develop the use case. This is the proper way, the below suggestions are work arounds.
ii) You could have the playbook call back to the SecOps API to create 1 new Alert for every Entity (so you would now have 5 new alerts + the original alert) so that you have 1 playbook per alert (as per i above), this would require you to do some dev work to process the data
iii) You could write some custom python to handle an array of input and then do things, it can be done but I recomment against this. 
iv) Playbook looping could handle this and is a roadmap item, I can't provide any dates for this feature. This path depends on if the above work, and your timeframes for this use case to go live. 

HTH

Hi @ylandovskyy! 

There are several alerts I'd like to do this with including Azure logs and Okta logs. I'd rather use detections to create them than connectors so that I have the freedom to group logs from different sources, etc. 

Hi @SoarAndy ,

I want to confirm my assumption that playbooks only run for alerts that are in a case, is this correct? It's been my experience. I've used custom trigger with alert.name set to the detection name. 

My issue is that playbooks aren't being ran for the alerts at all, I believe because cases aren't being created for them. I'd rather use the recommended solution but appreciate the inclusion of others. 

I did get this to work when the source is a connector not a detection (scheduled connector), it creates one case per alert and runs the playbook. 

The system will force every Alert into a Case. You cannot have an Alert that is not in a Case.

Playbooks MUST run at the Alert level (this may change in the long future)

Custom Triggers for Alert.Name is a good idea. I suggest that any Playbook that has a trigger for specific Alert Name should be a priority 1, triggers for source vendor should be priority 2, and at priority 3 you can have a 'default triage SLA assign' playbook.  This is not mandatory, but is a good starting point

Find the Alert you want to test against, find the right icon three dots and "ingest as test case".  A new Case with 1 Alert will appear in your case queue. You can then put your Playbook into Simulator mode and your 'Simulated Case' will appear in the list.  Running the playbook you will see if the Trigger is compatible. 

As above, all Alerts WILL be in a Case, so this it not a reason.  If your Alert/Case is not in the case queue on the left side, check a) if the Alert was ever ingested b) if the Alerts/Case was already closed using 'SOAR Search'

Hi @SoarAndy, 

If I'm missing something I apologize, but please see the below rule which is not mapped to a case and still shows status as "new". We are a NetEnrich customer so I'll check with them if they are doing anything unusual here.

I knew I was missing something simple. I was not aware of the Google Chronicle/SIEM Connector which allows me to create cases/SOAR alerts from SIEM detections. That fixed my issue.