Azure Workbooks are surprisingly capable and frustrating. In many ways, they are far more powerful than they appear at first glance. The UI does not always make it obvious where things live or how features connect, so it takes some effort to learn which buttons to push and in what order. Like many things in Azure, they are simple to learn and difficult to master.
Once you get past that learning curve, Workbooks start to feel less like dashboards and more like a lightweight application layer inside the Azure portal.
Why Workbooks Are So Easy to Use
Workbooks require almost no setup. There is no additional cost. There is no infrastructure to deploy, no backend service to maintain, and no separate authentication model to manage. Everything runs inside the Azure portal and uses the viewer’s existing RBAC permissions. Access control is already handled, which removes a lot of overhead.
They also work very well as a replacement for saved queries. Instead of digging through query history or maintaining a separate library of KQL snippets, you can store queries in a structured format, parameterize them, and run multiple queries together. This makes them easier to retrieve, easier to reuse, and easier to share.
There is also a practical advantage here. By breaking logic into multiple tiles, you can work past some of the limitations of a single query. Complex logic becomes easier to manage, and long queries become more readable when split into steps. You are not necessarily making things more efficient, but you are making them more usable.
Workbooks are also highly portable. You can export the template, share it, and even load and use it without saving. That is particularly useful when working in environments where you only have read access. You can still run and explore a workbook without leaving anything behind.
The tradeoff is that Workbooks are limited to the Azure portal. If you need to share content with users outside of Azure, tools like Power BI are still a better fit.
Moving Beyond Log Analytics
Log Analytics is where most workbook usage starts, but it is only part of the picture.
Azure Resource Graph is best thought of as the registry or configuration file for Azure. It tells you what exists, where it is, and how it is configured at a high level. It is fast, works across subscriptions, and is ideal for inventory and validation scenarios.
At some point, you will run into situations where Resource Graph is not enough. That is where Azure Resource Manager (ARM) queries come in. These call the live Azure API and return full configuration details. They are slower and more verbose, but they give you precision when you need it.
A practical pattern is to use Resource Graph to find resources at scale, then use ARM to inspect specific resources in detail, and Log Analytics or ADX to understand activity over time.
Azure Data Explorer (ADX) is another option that is often overlooked. It is designed for high-performance querying of large datasets and is useful when Log Analytics starts to feel constrained, either from a performance or cost perspective.
Workbooks also support querying across multiple Log Analytics workspaces, and even across tenants when the proper access is in place. This allows you to centralize views without needing to duplicate data.
Bringing in Data That Is Not in Azure
Not everything you need lives in Log Analytics or Resource Graph. Workbooks give you a few ways to bring in external or custom data.
The simplest option is Custom Endpoint. This allows you to call an API, return JSON, and display or merge the results. It works well for enrichment scenarios such as pulling ownership data from a CMDB or adding threat intelligence.
If you need deeper integration, Custom Resource Providers (CRP) allow you to register your API as an Azure resource. This adds RBAC control and makes the data behave like it is native to Azure.
For simpler needs, JSON query blocks are often enough. They let you define a static dataset directly in the workbook, which is useful for lookup tables, parameter lists, or lightweight configuration.
Merge: Connecting Everything Together
Merge is one of the most powerful and underused features in Workbooks. It allows you to combine data from different sources into a single view.
For example, you might take a list of resources from Resource Graph, combine it with activity data from Log Analytics, and enrich it with ownership data from JSON or an API. This lets you connect inventory, activity, and context in a way that would be difficult to achieve in a single query.
This is where Workbooks start to feel more like a tool than a report.
Parameters: The Engine Behind Interactivity
Parameters are what make Workbooks interactive, and this is where a lot of the power comes from.
Every tile that references a parameter is effectively listening for changes. When a parameter is updated, any dependent tile automatically refreshes. This creates a reactive experience where the workbook responds immediately to user input.
A common pattern is to use one tile to generate a list of values, allow the user to select one or more items, and export that selection as a parameter. That parameter is then used by other tiles. This allows you to pass values between tiles and build a guided workflow.
Parameters also work with conditional visibility. You can hide or show entire sections based on parameter values, which helps control both the user experience and when queries execute.
During development, the Parameters query block is extremely useful. It shows the current state of parameters, including whether a value is a single item or a list.
Visualizing and Passing Data Between Tiles
The primary query tile is more flexible than it first appears. The same dataset can be rendered in multiple ways, such as a table, a time-based chart, or a pie chart. This allows you to reshape how data is presented without rewriting the query.
Selections from these visuals can also be exported as parameters. This means a user can click on a row in a table or a segment in a chart, and that selection can drive other parts of the workbook.
Workbooks also support images and video, which can be useful for adding context, documentation, or training content directly into the experience.
Practical Limits to Keep in Mind
There are a few practical limits that directly influence how you design a workbook.
Query tiles have a hard limit of 10,000 rows. Even before that point, large datasets can become difficult to work with and slow to render.
If you are using tables to export selected values as parameters, the “select all” option only works when the table contains 150 rows or fewer. Beyond that, selection behavior becomes inconsistent.
KQL itself also has limits to consider. Complex queries, large joins, or long time ranges can introduce performance issues or query timeouts. Breaking logic into multiple tiles can help, but it also increases the total number of queries being executed.
Each tile runs independently, and Merge happens after those queries complete, which can add overhead.
Workbooks also do not natively support Defender Advanced Hunting queries. The most common approach is to send that data into Log Analytics or Sentinel and query it from there. If that is not possible, you can call the Defender API through a Custom Endpoint.
Adding Intelligence with Foundry LLM
Workbooks are very good at collecting and organizing data, but they do not interpret it. This is where integrating an LLM from Azure AI Foundry can add value.
Using a Custom Endpoint, you can send selected data or summarized results to an API that calls an LLM and returns structured output such as a summary, risk assessment, or recommended actions.
The key is to use this selectively. LLM calls introduce latency and require careful handling of data, so they are best triggered on demand rather than on initial load. In an upcoming post, I will walk through a full example using Merge and a Custom Endpoint with Foundry, along with a supporting project release.
Final Thought
Most Workbooks stay close to simple queries and tables. The real value shows up when you start combining data sources, chaining parameters, and controlling how and when things execute.
If you have only used Workbooks for basic queries, it is worth spending time exploring beyond the obvious. There is a lot more capability here than the UI initially suggests, and I will be demonstrating these patterns in upcoming posts and examples.