# Distinguish an alert's query target from its affected configuration items

> Which common-schema field should an integration inspect before assigning a log-search alert to an asset?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-272-distinguish-an-alert-s-query-target-from-its-affected-configuration-items/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:27:24+00:00
- Modified: 2026-09-10T01:23:48+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Which common-schema field should an integration inspect before assigning a log-search alert to an asset?

## Potentially affected

Integrations consuming Azure Monitor common-schema log-search alerts.

## DSE recommendation

Preserve the alert target and configuration items separately, and validate asset correlation against real payloads from the configured rule version.

## Article

## Source facts

In Azure Monitor’s common schema, alertTargetIDs identifies the alert’s ARM targets. For a log-search alert defined on a workspace or Application Insights resource, that target is the workspace or application. configurationItems can instead identify the resources that supplied the data. Microsoft documents its use for configuration-database correlation. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-common-schema).

For Scheduled Query Rules API version 2021-08-01, configuration items come from explicitly declared dimensions, with priority _ResourceId, ResourceId, Resource, then Computer. Earlier versions derive them implicitly from results. The separate alertRuleId property is not present in every alert type or API version. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-common-schema).

## Applicability

Use this distinction for integrations consuming Azure Monitor common-schema log-search alerts. Record the generating rule and API version before deciding what a particular field means in the integration.

## DSE recommendation

DSE recommends preserving both target and configuration-item fields in the incoming record. Define an explicit mapping for asset ownership instead of assigning every workspace-scoped alert to the workspace itself. Treat an absent identifier as an exception for review, not permission to invent an affected asset. Keep correlation failures visible to the integration owner.

## Verification

Inspect sanitized payloads from a known resource and compare their fields with the rule’s dimensions and expected asset. Include a missing-field case in the parser test. Confirm that the resulting ticket retains the original alert identity and correctly separates the query scope from the investigated resource.

## Official references

[Microsoft Learn: Common alert schema](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-common-schema).

## Primary reference

- Name: Common alert schema for Azure Monitor alerts - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-common-schema
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish an alert's query target from its affected configuration items,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-272-distinguish-an-alert-s-query-target-from-its-affected-configuration-items/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.