Skip to content

[Bug] Azure Monitor Workbooks cannot query Service Groups — crossComponentResources does not support serviceGroups scope #3154

@ricardo2009

Description

@ricardo2009

Summary

Azure Monitor Workbook parameters using queryType: 1 (Azure Resource Graph) cannot list or query Service Groups (microsoft.management/servicegroups in resourcecontainers). The root cause is that crossComponentResources only generates a subscriptions scope in the ARG POST body, but Service Groups require the serviceGroups scope to return results.

The same KQL query works perfectly in Azure Resource Graph Explorer but returns 0 rows inside the workbook.

Environment

  • Azure Portal: portal.azure.com (production)
  • Workbook schema: Notebook/1.0
  • ARG API version: 2024-04-01
  • Service Groups API: 2024-02-01-preview (Public Preview)
  • Tenant: Has 4 Service Groups with 37+ member resources across 1 subscription

Reproduction Steps

1. Create a workbook parameter with this ARG query

{
  "type": 2,
  "query": "resourcecontainers\n| where type == 'microsoft.management/servicegroups'\n| project value = name, label = name",
  "crossComponentResources": ["{Subscription}"],
  "queryType": 1,
  "resourceType": "microsoft.resourcegraph/resources"
}

2. Open the workbook from a subscription context

The dropdown is empty — 0 results.

3. Run the same query in Azure Resource Graph Explorer

The query returns all Service Groups in the tenant.

Root Cause Analysis

The Azure Resource Graph API supports three scope types in the POST request body:

// Scope 1 — Subscriptions (what the workbook sends)
{ "subscriptions": ["sub-id"] }

// Scope 2 — Management Groups
{ "managementGroups": ["mg-id"] }

// Scope 3 — Service Groups (what is REQUIRED)
{ "serviceGroups": ["tenant-id-or-sg-name"] }

Service Groups only appear when queried with the serviceGroups scope. The other two scopes return 0 results for resourcecontainers | where type == 'microsoft.management/servicegroups'.

Evidence (tested via az rest against ARG API 2024-04-01)

Scope in POST Body Result
"subscriptions": ["73155e11-..."] 0 Service Groups
"managementGroups": ["feb7e188-..."] 0 Service Groups
"serviceGroups": ["feb7e188-..."] (tenant root) 4 Service Groups
"serviceGroups": ["SG-AI-Platform"] (specific SG) 1 SG + 58 scoped resources
"subscriptions": [...] + "serviceGroups": [...] (mixed) 0 Service Groups (subscriptions takes precedence)

Key Insight

The workbook runtime translates crossComponentResources: ["{Subscription}"] into "subscriptions": [...] in the ARG POST body. There is no mechanism in the workbook parameter schema to instruct the runtime to use "serviceGroups" scope instead.

Expected Behavior

Workbook ARG parameters should be able to query Service Groups. Possible solutions:

  1. Add serviceGroups as a supported scope type in crossComponentResources — e.g., allow crossComponentResources to accept Service Group resource IDs.
  2. Support a new crossComponentResourceType property that lets the author specify the scope type (subscriptions, managementGroups, or serviceGroups).
  3. Auto-detect scope from resource type — when the query targets resourcecontainers filtered by microsoft.management/servicegroups, the runtime could automatically include the tenant-level serviceGroups scope.

Workaround Status

  • Opening the workbook from a Service Group context in the Portal does inject the correct scope, but this is not practical for a workbook designed to provide a holistic multi-scope overview.
  • queryType: 12 (ARM Endpoint) could potentially call the ARG POST endpoint directly with the correct body, but this is a complex workaround for what should be a native capability.
  • Graceful degradation is implemented: when the dropdown is empty, the workbook falls back to subscription-level filtering via a datatable + union pattern with value::all.

Impact

Service Groups are in Public Preview and represent the future of logical resource grouping in Azure. Workbooks that want to leverage Service Groups as a filter dimension are currently blocked unless the user navigates to the workbook from within a Service Group context — which defeats the purpose of a centralized assessment dashboard.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions