Skip to main content

 Hello,

I currently have several alarms in the SOAR that are based on the same KQL rule in Sentinel. Sometimes, as described in the connector, the KQL is executed and the event data is taken over. In other cases, the SecurityAlert table is read.

Connector Description: "Both scheduled and NRT alerts are by default ingested using the log analytics KQL queries to get alert and event data"

We're using the Microsoft Azure Sentinel Incident Connector v2 in Version 52, today I've updated to 53

As an example, I have two screenshots: both SOAR incidents were generated on different days using the same connector in the same SOAR environment. Both are originating from the same Sentinel Scheduled Alert.

 

 

In the "bad" example the Name of the Event equals the Sentinel AlertID from the SecurityAlert Table.
But no infomation why the Incident was created in Sentinel - this originates from the KQL query of the Alert.

Am I'm doing something wrong the outcome of the ingestion seems unpredictable ?

Best regards 

Dominik

Update:
With the new Version of the Connector (53) I'm getting this error everytime when opening an event of an SOAR Alert

Hey @Dominik_Albrink,


This is happening, because data related to the Azure Sentinel Alert can become populated at different time intervals. In the current version of the connector, there is logic that if API returned us information about associated entities, then the Alert is being created without waiting for "Scheduled Alert/NRT" object.


We received feedback that this is no optimal for all tenants, so we will release an update (ETA 2 weeks), which will allow you to control this logic and allow the connector wait until the "Scheduled Alert/NRT" object itself will be available before creating an Alert in SecOps.

@Dominik_Albrink  for the second issue, can you check if you are seeing it today? We had some changes to the internal API that was already reverted, so you shouldn't see this error anymore.

Hey @Dominik_Albrink,


This is happening, because data related to the Azure Sentinel Alert can become populated at different time intervals. In the current version of the connector, there is logic that if API returned us information about associated entities, then the Alert is being created without waiting for "Scheduled Alert/NRT" object.


We received feedback that this is no optimal for all tenants, so we will release an update (ETA 2 weeks), which will allow you to control this logic and allow the connector wait until the "Scheduled Alert/NRT" object itself will be available before creating an Alert in SecOps.


Hi,
thanks for the update, we will test it as soon as it becomes available.

@Dominik_Albrink  for the second issue, can you check if you are seeing it today? We had some changes to the internal API that was already reverted, so you shouldn't see this error anymore.


hello again,
I had to relog, but it seems the Error is gone. 🙂

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.