Supported triggers and actions in Microsoft Sentinel playbooks
This article describes the triggers and actions supported by the Logic Apps Microsoft Sentinel connector. Use the listed triggers and actions in Microsoft Sentinel playbooks to interact with your Microsoft Sentinel data.
Important
Noted functionality is currently in PREVIEW. See the Supplemental Terms of Use for Azure Previews for additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
Prerequisites
Before you start, make sure that you have the following Azure permissions required to use Microsoft Sentinel connector components:
| Role | Use triggers | Get available actions | Update incident, add a comment |
|---|---|---|---|
| Microsoft Sentinel Reader | ✓ | ✓ | - |
| Microsoft Sentinel Responder/Contributor | ✓ | ✓ | ✓ |
For more information, see Roles and permissions in Microsoft Sentinel and prerequisites for working with Microsoft Sentinel playbooks.
Supported Microsoft Sentinel triggers
The Microsoft Sentinel connector, and therefore Microsoft Sentinel playbooks, support the following triggers:
Microsoft Sentinel incident. Recommended for most incident automation scenarios.
The playbook receives incident objects, including both entities and alerts. This trigger allows you to attach a playbook to an automation rule that can be triggered whenever an incident is created or updated in Microsoft Sentinel, applying all the benefits of automation rules to the incident.
Microsoft Sentinel alert (Preview). Recommended for playbooks that must be run manually on alerts, or for scheduled analytics rules that don't generate incidents for their alerts.
- This trigger can't be used to automate responses for alerts generated by Microsoft security analytics rules.
- Playbooks using this trigger can't be called by automation rules.
Microsoft Sentinel entity. Recommended for playbooks that must be run manually on specific entities from an investigation or threat hunting context. Playbooks using this trigger can't be called by automation rules.
The schemas used by these flows aren't identical. We recommend using the Microsoft Sentinel incident trigger flow for most scenarios.
Incident dynamic fields
The Incident object received from Microsoft Sentinel incident includes the following dynamic fields:
| Field name | Description |
|---|---|
| Incident properties | Shown as Incident: <field name> |
| Alerts | An array of the following alert properties, shown as Alert: <field name>. Since each incident can include multiple alerts, selecting an alert property automatically generates a for each loop to cover all alert in the incident. |
| Entities | An array of all the alert's entities |
| Workspace info fields | Details about the Microsoft Sentinel workspace where the incident was created, including: - Subscription ID - Workspace name - Workspace ID - Resource group name |
Supported Microsoft Sentinel actions
The Microsoft Sentinel connector, and therefore Microsoft Sentinel playbooks, support the following actions:
| Action | When to use it |
|---|---|
| Alert - Get Incident | In playbooks that start with Alert trigger. Useful for getting the incident properties, or retrieving the Incident ARM ID to use with the Update incident or Add comment to incident actions. |
| Get Incident | When triggering a playbook from an external source or with a non-Sentinel trigger. Identify with an Incident ARM ID. Retrieves the incident properties and comments. |
| Update Incident | To change an incident's Status (for example, when closing the incident), assign an Owner, add or remove a tag, or to change its Severity, Title, or Description. |
| Add comments to incident | To enrich the incident with information collected from external sources; to audit the actions taken by the playbook on the entities; to supply additional information valuable for incident investigation. |
| Entities - Get <entity type> | In playbooks that work on a specific entity type (IP, Account, Host, **URL, or FileHash) which is known at playbook creation time, and you need to be able to parse it and work on its unique fields. |
Tip
The actions Update Incident and Add a Comment to Incident require the Incident ARM ID.
Use the Alert - Get Incident action beforehand to get the Incident ARM ID.
Supported entity types
The Entities dynamic field is an array of JSON objects, each of which represents an entity. Each entity type has its own schema, depending on its unique properties.
The "Entities - Get <entity type>" action allows you to:
- Filter the array of entities by the requested type.
- Parse the specific fields of this type, so they can be used as dynamic fields in further actions.
The input is the Entities dynamic field.
The response is an array of entities, where the special properties are parsed and can be directly used in a For each loop.
Currently supported entity types include:
The following image shows an example of available actions for entities:
For other entity types, similar functionality can be achieved using Logic Apps' built-in actions:
Filter the array of entities by the requested type using Filter Array.
Parse the specific fields of this type, so they can be used as dynamic fields in further actions using Parse JSON.
Related content
For more information, see: