What's New: Azure Sentinel Logic Apps Connector improvements and new capabilities

Published Nov 30 2020 09:14 AM 9,027 Views

Azure Sentinel Logic Apps connector is the bridge between Sentinel and Playbooks, serving as the basis of incident automation scenarios. As we prepare for new Incident Trigger capabilities (coming soon), we have made some improvements to bring the most updated experience to playbooks users.

Note: existing playbooks should not be effected. For new playbooks, we recommend using the new actions.



  • Operate on most up-to-date Incidents API
  • New dynamic fields are now available 
  • Less work to accomplish incident changes
  • Assign Owner ability in playbooks
  • Format rich comments in a playbook



What's new?


Update Incident: One action for all Incident properties configuration

Now it is simpler to update multiple properties at once for an incident. Identify the Incident you want to operate on and set new values for any field you want. 


Update Incident replaces the actions: Change Incident Severity, Change Incident Status, Change Incident Title, Change Incident Description, Add/Remove Labels. They will still work in old playbooks, but eventually will be removed from the actions gallery for future use.




Assign Owner in playbooks

As part of new Update Incident, it is now possible to assign an owner to an incident in a playbook. For example, based on incident creation time and SecOps staffing information (for example, from a you can assign the incident to the right shift owners:

  1. Set Assign/Unassign owner to Assign
  2. Set Owner with the Object ID or User Principal Name.


Post Rich Comments with HTML editor

Recently, Azure Sentinel added support for HTML and Markdown for Incident Comments. Now, we added an HTML editor to the Add comment to Incident so you can format your comments.




One identifier for working on Azure Sentinel Incidents

Previously, you had to supply 4 fields in order to identify the incident to update. New Update Incident and Add Comment to Incident require only one field (instead of 4) to identify the incident that meant to be changed: Incident ARM ID.


If your playbooks start with Azure Sentinel Alert trigger (When an Azure Sentinel Alert is Triggered), use Alert - Get Incident to retrieve this value.


Get Incident: Now with most updated Sentinel API

Alert - Get Incident allows playbooks that start with Azure Sentinel Alert Trigger (When an alert is triggered) to reach the incident that holds the alert.


Now, new fields are available and are aligned to the Incident API

For example, Incident URL can be included in an Email to the SOC shared mailbox or as part of a new ticket in Service Now, for easy access to the incident in the Azure Sentinel portal.




This action's inputs have not changed, but the response became richer:





In addition, we supplied another action called Get Incident which allows you to identify incidents using the Incident ARM ID, so you can use any other Logic Apps trigger and still get Incident details. It returns the same Incident Schema. For example, if you work with another ticketing system which supports triggering Logic Apps, you can send the ARM ID as part of the request.




Get Entities: names change

As we prepare for our new Incident Trigger experience, when entities will be received both from incidents an alerts, we changed the name of the actions Alert - Get IPs/Accounts/URLs/Hosts/Filehashes  to Entities - Get IPs/Accounts/URLs/Hosts/Filehashes. 




Learn more

Azure Sentinel Connector documentation


Valued Contributor

Awesome changes!


One question: Will support for dynamic links be added to the 'Add comment to incident' in the future?

I would love to use a dynamic value for the value of the link.

Occasional Contributor

@liortamir thank you for the updates. The IncidentURL was awaited and will be helpful.

Had a request to make the When_Azure_Sentinel_incident_creation_rule_was_triggered_(Private_Preview_only) public allowing us to use it with incidents. Currently we can't map it to analytics rules and that was an issue since we are aggregating alerts into incidents.

And for 90% of rules we don't wan't the playbook to run per alert rather per incident, so speeding this one up would be really helpful.

Thanks again. :)

Thanks @liortamir for Sharing this with the Community :smile:


@Thijs Lecomte , Great feedback! We will check that, definitely important usage. 

@Joseph-Abraham , stay tuned - this is very soon public. We are going to present new automation capabilities beginning of new year, including Incident Trigger becoming public. 

Thanks @James van den Berg ! :)

Occasional Contributor

@liortamir The above promise of releasing the Sentinel trigger as public hasn't materialized yet.

Sorry to say but this makes life difficult for a lot of us.

Expecting a faster turnaround.


@Joseph-Abraham  @liortamir 


I am in the middle of trying to make a decision for my MSSP on which ticketing solution to choose to integrate with Sentinel.


This ticketing system will be crucial to my operations as an MSSP.


What are some recommendations? Which is the easiest to deploy currently?

I really just need to create tickets between my clients and the MSSP, would like to include automation, etc.

Occasional Contributor

I have worked with Service Now(Snow) and Jira integration and in my experience I believe Snow is better.

You can test it out first to see if it meets your clients requirements.

Check out the playbooks in the below link, do a Cntrl+F and search for "SNOW" and Jira.



Example of opening SNOW tickets:



Joseph, I talked with SNOW yesterday.

It's a minimum of 25 licenses , at 42,000 $ per year?


We are currently using event hubs to sync incidents between Sentinel & Resilient and parsing Json to get key incident details such as the incident id. v2 of the 'Add comment to incident' allow us to use the parsed json 'incidentid'. Will this id work in place of the 'Incident ARM id' that is now required by the new v3 connector? 


Many thanks,



Frequent Contributor

The Create job automation account operator is missing a field.
The operator doesn't contain a parameter field:


But the missing field is shown here in the screenshot for this playbook.

It appears there used to be such a parameter or this has somehow been customized to include the parameter field?:





If you use the 'peek code' option, or view the json from the playbook template you can see this:

So it appears the operator has been hardcoded to accept the 'Name' parameter??

Was this configuration modified at the JSON level and then imported into Azure?
Is there any documentation explaining how to configure this?
Thank you.





Version history
Last update:
‎Nov 02 2021 06:27 PM
Updated by: