Get full data into Playbook

Valued Contributor



We are currently trying to automate some alerts through Playbooks.

We created a custom alert that checks for Impossible Travel Alerts from MCAS.

This works well. But the issue is that some data that is in the SecurityAlerts table (like ExtendedProperties and Entities) isn't forwarded to the Logic App when it's triggered by Sentinel.

I attached a screenshot of what data is forwarded through a logic app


Because Sentinel Entities do not support an array, but only one value. It's not possible to use those, because an impossible travel alert has multiple IP's.


So we are looking for another way to get all the data of a Sentinel alert into a playbook.


Should we query log analytics for this? I don't really like doing this, because this seems like an unnecessary step. 


Does anybody have something for this?

13 Replies

@Thijs Lecomte  Not sure what you mean when you say that Entities do not support arrays.  If the alert that creates the Incident finds multiple events and each of those events has matching entities, then the incident will have  multiple entities.


I currently have one incident that is made up of 13 events and has 5 IP and 6 Account Entities in it.  Using a Playbook to write the Entities to a Teams message I see that it writes out the Entities in a JSON array.


Looking at your image it shows the same thing just that, in your case, you only have 1 Entity listed

Thanks for the response.
The alert is have only has one event.

The event that comes from MCAS.
I can understand that multiple events in one alert can lead to multiple entities.

But can one event in an alert lead into multiple entities?

Or is there another way to get the full event details into Playbooks?

@Thijs Lecomte One event will only have up to a single value for each of the entities. 


Any chance that will be changed in the future?

Or any way to get the full details through the playbook?

@Thijs Lecomte I would not expect this to change.    What do you mean when you say full details?  What is missing?

@Thijs Lecomte This is something I have done and probably you could do.


Entities and Extended properties are JSON parameters. Using the data operations connector parse these parameters. You could get the JSON schema from the entities/extended properties logs. 

Almost all of the times the scheduled query is available in the Extended properties. By parsing you will convert JSON into String and take the Query parameter out. Initialize the variable naming it as XYZ and use Query with a time period(this is must). 

Using Azure Log Analytics run this initialized variable and you should be good to go.. Seems like a lot of pain but works just fine.


That's how I do it too ATM.

But this means there is an extra query to log analytics which seems unnecessary to me... Shouldn't this be available by default?


@Gary Bushey  Some data that I see in the SecurityAlerts table isn't able in the Playbook. These are columns like 'Entities' and 'ExtendedProperties' (these are columns that contain extra data from MCAS).

@Thijs Lecomte I believe what @Pranesh1060 meant is that you can take the Extended properties and the Entities fields and use the Logic Apps Parse JSON action to extract the information.   There is no reason to perform another query against Log Analytics.



Hi @Gary Bushey 

I have 2 questions about creating playbooks for Sentinel.


1. Is there a basic rule for when you need to use the parse json function and when you don't?

eg. you can NOT:

"When Azure Sentinel incident creation rule was triggered" > "Send an email (v2)"

you CAN:

"When Azure Sentinel incident creation rule was triggered" > "parse json" > "Send an email (v2)"


However you CAN do this w/o the need for parse json:
"When Azure Sentinel incident creation rule was triggered"  > "Run query and list results"


2. Secondly, when using 'parse json', how do you create the json template? Is it usually just a simple format based on the fields of interest? eg.







Thank you.

@bobsyouruncle 1) I don't think there is a set rule, it really depends on what type of information you are trying to obtain

2)  Usually, I run the playbook without the parse JSON action first, look at the run, copy the data that I need to parse from the output of the action that creates it, and then paste it into the parse JSON action as sample data and let the action handle the parsing. 

Thanks @Gary Bushey 

"look at the run" is what I needed to know, thanks!


What I'm saying about the parse json rule is that some operators don't need it as a predecessor and some do - for example if you want to include fields from your alert in the email function you must use parse json first. But maybe the send email is a special exception?

@bobsyouruncle It depends on the field you are looking to use.  Some of the information is stored as JSON and some of it is returned directly as a variable.

thanks Gary.
Turned out a bit more practice with playbooks showed me the light :).
simply monitoring the output results and understanding where to place your functions (in or our of a FOR loop) were my weaknesses.