Configure the Microsoft Sentinel SIEM and platform

Suppose a new SOC (security operations center) analyst joins your team: Microsoft recommends Microsoft Sentinel Responder for security analysts^[1], the role that lets them view and manage incidents. Other platform settings shape the rest of their work: retention settings decide how long data stays fully available for real-time analytics, including high-performance queries and threat hunting^[2], workbooks add tables and charts with analytics for logs and queries^[3], and SOC optimization recommendations identify tables with low usage^[4] so a SOC avoids paying for more data than it needs. This page covers those four settings in Microsoft Sentinel, Microsoft's cloud SIEM (security information and event management) service: roles, data tiers and retention, workbooks, and SOC optimization.

Neighboring SC-200 exam objectives

The other exam objectives in this domain cover the neighboring jobs. Configure automation for Microsoft Defender XDR and Microsoft Sentinel includes automation rules and playbooks, Ingest data into the Microsoft Sentinel SIEM and platform includes data connectors and collection rules, and Configure detections includes analytics rules. This page covers what surrounds the data once it lands: who may act on it, where it is stored and for how long, how it is visualized, and how Sentinel recommends tuning it.

One workspace, managed from the Defender portal

Sentinel is enabled on a Log Analytics workspace, the Azure Monitor data store for workspace-ingested logs; this is the basis for the workspace-based SIEM configuration covered here. Day-to-day management happens in the Microsoft Defender portal, where Sentinel sits beside Defender XDR: after March 31, 2027, Sentinel is no longer supported in the Azure portal and is available only in the Defender portal^[5]. A few tasks covered below still run on the Azure side today, such as managing Basic plan tables (also called Basic Logs tables; Log Analytics table plans and plan switches explains table plans) and printing a workbook, and the sections that cover them say so.

In short, Sentinel settles who may act through its built-in roles^[1], where data lives and for how long through table tiers and retention^[2], how data is shown through workbooks^[3], and whether ingested data delivers security value through SOC optimization recommendations^[4].

Choosing a Sentinel role means finding the lowest rung of a three-rung ladder (a study-guide image, not a Microsoft term) that still covers the job, because each rung includes everything below it. Sentinel SIEM permissions use Azure RBAC (role-based access control), Azure's authorization system, in which a role assignment binds a principal (a user, group, or service principal) to a role at a scope. Microsoft's built-in role table^[1] shortens the Microsoft Sentinel Reader, Responder, and Contributor names itself, as in the Responder entry "All Reader permissions, plus manage incidents", while the general Azure Owner, Azure Contributor, and Azure Reader roles^[1] are separate roles that grant broad access across Azure resources. Two terms appear in the table: Content hub is Sentinel's catalog of packaged solutions and standalone content items (data connectors, analytics rules, workbooks, and more) that you install into the workspace, and a playbook is a workflow built on Azure Logic Apps, where each Logic App is an Azure resource separate from the workspace. Sentinel's built-in Azure roles^[1] form the ladder:

Role	What it adds	Not included
Microsoft Sentinel Reader	View data, incidents, workbooks, recommendations, and other resources	Managing incidents, creating or editing content
Microsoft Sentinel Responder	Everything Reader has, plus manage incidents	Creating or editing analytics rules and other resources, managing Content hub
Microsoft Sentinel Contributor	Everything Responder has, plus create and edit resources (analytics rules, workbooks, and more) and install or update solutions, which Microsoft's role table (linked above) lists as Manage content hub	Creating or editing playbooks

None of the three ladder roles runs playbooks: Microsoft's role table also marks Run playbooks as outside Reader, Responder, and Contributor, and Task roles beyond the ladder below covers the roles that do. Microsoft's recommended assignments^[1] give security analysts Responder, and give security engineers, and service principals that run automated management tasks, Contributor.

Grants add up; they never subtract

Azure role assignments are cumulative, so a lower rung never caps a higher one: a user with both Microsoft Sentinel Reader and Contributor may have more permissions than intended^[1]. Adding Reader to someone who already holds a write role restricts nothing. Watch the name collision here: the general Azure Contributor role is not Microsoft Sentinel Contributor. It is one of the broad Azure roles (with Azure Owner and Azure Reader) that reach the workspace along with every other resource in scope, and the Log Analytics Contributor and Log Analytics Reader roles also grant workspace access. Least privilege therefore means reviewing every assignment that applies to a person, direct or inherited. Microsoft recommends the roles with the fewest permissions^[1] and limits Global Administrator (a Microsoft Entra ID role, not an Azure role) to emergency scenarios.

The figure below draws the ladder as nested sets, because Microsoft describes Responder as all Reader permissions plus managing incidents, and Contributor as all Responder permissions plus more^[1]; the cumulative rule sits underneath it. The takeaway: pick the lowest rung that covers the job, and remove a broader assignment rather than layering a narrower one on top.

Where a Sentinel role is assigned matters as much as which role it is, because Sentinel spans several Azure resources rather than one. Microsoft recommends assigning the roles to the resource group that contains the Sentinel workspace^[1], so that related resources such as playbooks (Logic Apps) are covered by the same assignments.

Assigning a role directly on the workspace is the alternative, and it brings follow-up work. Microsoft's role guidance^[1] names a SecurityInsights solution resource in that workspace that needs its own copy of the same role; you might need to assign the role on other resources too, and you must keep all of them in step over time.

Scope of the assignment	What it covers	Follow-up work
Resource group containing the workspace (recommended)	The workspace and the related resources in that group, such as playbooks	None beyond the assignment
The workspace itself	The workspace only	Assign the same role on the SecurityInsights solution resource, and on any other resources the user needs

A workspace-only assignment can leave a user able to work in the workspace but not with the playbooks next to it, because those Logic Apps are separate resources outside the assignment's scope. The figure below shows the three resources Microsoft names inside the resource group as separate boxes, because a workspace-scoped approach must assign each one separately; the highlighted workspace is the only one a workspace-only assignment reaches. What to remember: default to the resource group, and treat a workspace-scoped assignment as one of several assignments you must maintain.

Some Sentinel jobs need a role outside the Reader, Responder, Contributor ladder, either because the work happens on a different resource or because it needs a permission from a different system. A detection engineer with Microsoft Sentinel Contributor, for example, still cannot change a playbook's steps, because playbooks are Logic Apps and Contributor's reach stops at Sentinel content. Microsoft lists additional roles for specific tasks^[1]:

Task	Role or permission needed
List, view, and manually run playbooks	Microsoft Sentinel Playbook Operator
Create or edit playbooks	Logic App Contributor on the playbook resource group
Let automation rules run playbooks	Explicit permissions for Sentinel's service account on the playbook resource group; assigning them requires Azure Owner
Create or delete workbooks	Microsoft Sentinel Contributor, or a lesser Sentinel role plus Workbook Contributor
Guest users assign incidents	Microsoft Entra Directory Readers plus Microsoft Sentinel Responder
Connect data sources	Write permission on the workspace, plus any extra permissions the connector's documentation lists
Manage Content hub content	Microsoft Sentinel Contributor at the resource group

• Playbook Operator runs playbooks but does not author them. The role lets someone list, view, and manually run existing playbooks; changing a workflow's steps needs Logic App Contributor. See also Configure automation for Microsoft Defender XDR and Microsoft Sentinel. Holding the role is not everything a run involves: Sentinel uses a special service account to run incident-trigger playbooks manually or from automation rules^[1], not the user's account, and the next bullet covers that account.
• Microsoft Sentinel Automation Contributor appears in the built-in role list, but it is not a role for people: it allows Sentinel itself to add playbooks to automation rules and is not used for user accounts^[1]. For an automation rule to run a playbook, Sentinel's service account needs explicit permissions on the playbook's resource group, and once it has them, any automation rule can run any playbook in that group.
• Workbook Contributor adds dashboard authoring without SIEM administration. Paired with Reader or Responder, it lets a dashboard author create and delete workbooks without Contributor's power over analytics rules.
• Guest analysts need a directory role to assign incidents. Directory Readers is a Microsoft Entra ID role, not an Azure role; regular (non-guest) users normally have directory-read permissions by default, rather than necessarily holding this named role. The fix is the directory role, not a promotion to Microsoft Sentinel Contributor, which adds SIEM rights but no directory lookup.

The takeaway: when the ladder seems to fall short, the missing permission usually sits on a different resource (a Logic App, a workbook) or in a different system (Microsoft Entra ID).

Where the SIEM uses Azure RBAC alone, data lake access comes from three systems, picked by scope: Microsoft Entra ID roles for every workspace in the lake, Azure RBAC roles for one workspace, and Defender XDR unified RBAC custom roles for system tables (unified RBAC and system tables are defined below). The data lake uses Microsoft Entra ID RBAC for its built-in and custom roles^[1], and an analyst's built-in Azure RBAC workspace roles also provide parallel permissions in data lake experiences. The Microsoft Sentinel data lake^[6] is a fully managed store that keeps a single copy of security data in open Parquet format for up to 12 years, queried with KQL (Kusto Query Language) or Jupyter notebooks. To use these permissions in the Sentinel data lake, onboard the workspace to the Defender portal and to the data lake.

Tenant-wide and workspace-scoped lake data access

Lake data access can be tenant-wide or workspace-scoped. A Microsoft Entra ID role grants data access across all workspaces in the lake at once; an Azure role on a single workspace grants it for that workspace only. For system tables, use a Defender XDR unified RBAC custom role over the Microsoft Sentinel data collection instead. Defender XDR unified RBAC is the Defender portal's own role model, in which custom roles are built from permissions organized into permission groups, such as Data (manage) in the Data operations group and Security data basics (read) in the Security operations group^[7]. System tables are built-in tables that store ingested asset data, not a name for every built-in workspace table. The Microsoft Sentinel data collection is the scope of a unified RBAC role assignment: an assignment's data collections grant access across all Sentinel workspaces or only selected ones, and the Sentinel data lake is listed there by default^[8]. It is unrelated to a data collection rule (DCR), which configures data ingestion. The rows that mention jobs mean lake jobs, such as a KQL job: a one-time or scheduled KQL query on data in the Sentinel data lake^[9]. The data lake permission tables^[1] map out both scopes:

Need	All workspaces: Microsoft Entra ID role	Workspace Azure RBAC or system-table unified RBAC
Read and query lake data	Global Reader, Security Reader, Security Operator, Security Administrator, or Global Administrator	Log Analytics Reader, Log Analytics Contributor, Microsoft Sentinel Reader, Microsoft Sentinel Contributor, Azure Reader, Azure Contributor, or Azure Owner on the workspace; for system tables, a unified RBAC custom role with Security data basics (read) over the Microsoft Sentinel data collection
Write to tables with KQL jobs or notebooks	Security Operator, Security Administrator, or Global Administrator	A role with workspaces/write, workspaces/tables/write, and workspaces/tables/delete on the workspace, such as Log Analytics Contributor; for system tables, a unified RBAC custom role with Data (manage) over the Microsoft Sentinel data collection
Create scheduled jobs or manage jobs	Security Operator, Security Administrator, or Global Administrator	No workspace-scoped option is listed

The operation names in the table are shortened from Microsoft.OperationalInsights/workspaces/write and its siblings, the Azure resource-provider operations a role must include. The workspace-scoped write path is also how you let someone configure connectors to that workspace, change its table retention, or create, update, and delete its custom tables.

A job-management role does not cover table settings: lake jobs are authorized by Entra roles, while changing a table's tier or retention is checked against the workspace's Azure RBAC operations or the unified RBAC Data (manage) permission, as Changing table settings is data management in Analytics retention and total retention describes.

In short: when a requirement names one workspace, use a workspace-scoped role rather than a tenant-wide Entra role, and when someone must run lake jobs, Security Operator is the least-privileged role on the list.

Broad workspace data-reader roles normally open all workspace data, so giving a team only some of the data needs a deliberate mechanism. Typically, users with access to a Sentinel-enabled workspace can read all of its data, including security content^[10]. Sentinel names two approaches for teams that need only certain data or tables^[1], and the choice depends on whether the boundary is a set of Azure resources or a set of tables:

• Resource-context RBAC grants access to Azure resources (a virtual machine, a resource group) instead of the workspace. Users then see only the logs those resources produced, either from the resource itself or through Azure Monitor with the query scope set to those resources.
• Table-level access (also called table-level RBAC, because Log Analytics manages it with role-based access control) restricts which tables of the workspace a user can read. Log Analytics documents four methods and recommends two of them, protected tables and granular RBAC^[11], over two earlier methods.

Resource-context RBAC in practice

Resource-context RBAC suits a non-SOC team, such as server owners who need the Windows events of their own servers. The resource-context RBAC scenarios^[10] contrast it with a SOC team's access:

Requirement	SOC team	Non-SOC team
Permissions	The entire workspace	Specific resources only
Data access	All data in the workspace	Only data for resources the team may access
Experience	The full Sentinel experience, limited by the user's Sentinel roles	Log queries and workbooks only

Two limits come with it. Data that is not an Azure resource, such as Syslog, CEF (Common Event Format), Microsoft Entra ID data, or data from a custom collector, needs its resource ID configured manually before resource-context access works. And because functions and saved searches are not supported in resource-centric contexts, Sentinel parsing and normalization are not supported for resource-context RBAC either.

A workbook filter is not a boundary

A workbook filter only changes what one report displays; the user's role still lets them query the underlying tables directly. Restricting data is the job of the two mechanisms above. What to remember: draw the data boundary in RBAC, by resource or by table, never in a visualization.

A table's tier decides which Sentinel features can read it, so choosing a tier is a feature decision before it is a cost decision. Sentinel retains data in two tiers, and Defender XDR hunting data starts in a third, the XDR default tier^[2]. The comparison table titled Analytics tier vs Data Lake tier vs XDR default tier on this page lines the three up on rows from Microsoft's tier comparison^[2], such as Best for and Ingestion cost; this section explains what each one means in practice.

Analytics tier

The Analytics tier is the hot, high-performance tier that makes data available for alerting, hunting, workbooks, and every other Sentinel feature, with full query capabilities in the Defender portal, the Azure portal, and APIs. Ingestion is billed at the standard rate and the query price is included. By default, Analytics tier data is also mirrored to the data lake for the same retention period, which is what lets total retention (next section) keep it longer at low cost.

Data Lake tier

The Data Lake tier is the low-cost cold tier: the table's data lives in the data lake only. It is not available to real-time analytics features and threat hunting^[2]; instead you reach it with KQL jobs, scheduled KQL or Spark jobs, notebooks, summary rules, and search jobs, and KQL and notebook jobs can promote data back to the Analytics tier. However, in advanced hunting, the Defender portal's query page for threat hunting, new Microsoft Sentinel customers can query Analytics and Data Lake tier tables^[12], but not an Analytics table's data beyond its Analytics retention period. A summary rule aggregates log data at a regular cadence and sends the results to a custom log table^[13], and a search job is an asynchronous query that fetches records into a search table in the workspace^[14]. It suits compliance logging, historical forensics, and low-touch data that no real-time alert needs. Its billing^[15] uses separate meters: data lake ingestion and data processing per GB for tables set to the Data Lake tier only, and data lake storage per GB per month for data that remains after the Analytics retention period, billed at a uniform 6:1 compression rate.

Keep two names apart. The Microsoft Sentinel data lake is the store, and the Data Lake tier is the setting that keeps a table only in that store. An Analytics tier table has a copy in the data lake as well, through the mirror.

XDR default tier

Defender XDR keeps its threat-hunting data in the XDR default tier, where advanced hunting can reach it for 30 days under the XDR license. Advanced hunting queries Defender XDR data and, once Sentinel is onboarded, Sentinel workspace data too, while Sentinel itself reaches Defender data only after raw Defender data is ingested into it^[12]. So in the Defender portal, hunting Sentinel data and hunting XDR data happen on the same advanced hunting page, but XDR default-tier data reaches no other Sentinel feature. XDR default-tier tables are not in the Sentinel workspace. On the Defender portal Tables page, a supported XDR table becomes a Sentinel table in the workspace once its retention is extended (Defender XDR tables in Sentinel's tiers below covers how), while the currently unsupported tables are listed as the XDR table type^[2], such as IdentityInfo: viewable, but not manageable there.

What a tier change breaks

When a table moves from the Analytics tier to the Data Lake tier, the Defender portal's Tables page warns^[7] that features relying on Analytics data stop functioning: alerting, advanced hunting, analytics rules, and custom detection rules. This is not a blanket loss of hunting access: new Microsoft Sentinel customers can still query Data Lake tier tables in advanced hunting^[12]. Some tables cannot move at all: certain XDR and Sentinel solution tables must remain in the Analytics tier^[7] because Microsoft security services need their data for near-real-time analytics. Sentinel solution tables is Microsoft's own term: it appears here, where certain of these tables must stay in the Analytics tier, and in its tier overview, where their Analytics retention can be extended to 90 days for free (What the included 90 days means below covers that allowance).

The takeaway: list every rule, hunting query, and workbook that reads a table before you move it out of the Analytics tier; Configure detections covers the analytics rules themselves.

Total retention is the data's whole retained lifetime, and Analytics retention is the hot stretch at its start; they are two separate settings on every Analytics tier table. On the Defender portal Tables page, Manage table sets Analytics retention from 30 days to two years and total retention up to 12 years^[7], and the part of total retention beyond Analytics retention is kept in the data lake at low cost. A table set to the Data Lake tier has a single Retention value instead, between 30 days and 12 years. In the Log Analytics Tables API the same pair appears as the retentionInDays and totalRetentionInDays table properties^[16].

Changing table settings is data management

Changing a table's tier or retention is a configuration change, not a query, so read access never covers it. On the Defender portal Tables page, viewing table settings needs Security data basics (read) in unified RBAC or workspaces/tables/read on the workspace, while configuring them needs Data (manage) or both workspaces/write and workspaces/tables/write^[7], as the Log Analytics Contributor built-in role provides. In Defender XDR unified RBAC, Data (manage) sits under the Data operations permissions group, and Security data basics (read) under the Security operations group^[7].

What the included 90 days means

The included 90 days is an allowance, not a setting. Sentinel solution tables can be extended to 90 days of Analytics retention for free^[2], and Analytics retention beyond that carries a prorated monthly retention charge. A table configured for 30 days keeps 30 days of hot data even though 90 would cost nothing more in retention, so raise the value to use the allowance. Applicable ingestion charges are separate from retention charges either way.

How changes take effect

The two settings react to changes differently, as what happens when you modify table settings^[2] describes:

Table setting change	What happens
Change Analytics retention on a table with data	Takes effect immediately
Shorten total retention	Microsoft waits 30 days before removing the data, so you can revert a mistake
Lengthen total retention	Applies to all data already in the table that was not yet removed

Microsoft's example: a table has 180 days of Analytics retention and, by default, 180 days of total retention. You cut Analytics retention to 90 days and leave total retention at 180. Data older than 90 days leaves Analytics retention at once, but data that is 90 to 180 days old stays in the data lake, where KQL jobs and search jobs can still reach it. The 30-day wait protects total retention only; it does not keep older data in the hot tier, so check rule and workbook lookback periods before you shorten Analytics retention. Lengthening total retention later cannot bring back data that was already removed.

The figure below traces that example along the data's age: after data leaves Analytics retention at day 90, data that is 90 to 180 days old stays in the data lake^[2]. The takeaway: for a short hot window plus long compliance history, set both values, keeping Analytics retention short and total retention long.

Defender XDR hunting data starts outside Sentinel's tiers, and each way of keeping it longer has its own cost profile. By default, Defender XDR retains threat-hunting data in the XDR default tier for 30 days, and that data is not ingested into the Analytics or Data Lake tiers^[2]. Setting the Analytics retention of a supported XDR table above 30 days on the Defender portal Tables page creates that table in the Sentinel workspace, in the Analytics tier with a mirror in the data lake.

The choices and their costs

Choice for a supported XDR table	What happens	Cost
Leave the default	30 days in advanced hunting, no Sentinel copy	Included in the XDR license
Extend Analytics retention to 31 to 90 days	Table created in the Sentinel workspace, mirrored to the data lake	Sentinel ingestion charges; storage free
Extend Analytics retention beyond 90 days	The same, for longer	Ingestion, plus Analytics storage beyond 90 days
Ingest into the Data Lake tier only	Data stored in the lake; the default 30 days of advanced hunting stay available at no extra cost	Ingestion, storage, and processing

Microsoft's tier overview describes those default 30 days as data that remains available in the Analytics tier^[2]; they are the XDR default tier's 30 days of analytics retention, which create no copy in the Sentinel workspace.

The XDR retention and cost examples^[2] show how the pieces combine. With 90 days of Analytics retention and 180 days of total retention, you pay Analytics ingestion, no Analytics storage (90 days are included), and 90 days of additional data lake retention. With lake-only ingestion and five years of retention, you pay ingestion and five years of data lake retention; the example table writes this case as 0 days of Analytics tier retention, which means the Data Lake tier choice with its single Retention value, not a value of the Analytics retention setting, whose minimum is 30 days. In every case, XDR data stays available through advanced hunting for at least 30 days. Free storage is therefore not free ingestion: extending to 90 days still adds Sentinel ingestion charges.

Ingesting through the XDR connector

If you enable the Microsoft Sentinel XDR connector in the Azure portal, the tables you select during setup are ingested into the Analytics tier and mirrored to the data lake, with a default retention of 30 days that you can extend up to 12 years; supported tables you did not select can be added by setting their retention above 30 days. Without the connector, you can still ingest supported tables the same way from the Defender portal.

Resetting retention stops ingestion

To stop ingesting into the Analytics tier, reset both Analytics retention and total retention to the default 30 days. Microsoft warns that this reset disables the connector in the Azure portal^[2], so check which Sentinel detections read those tables before treating it as a storage tweak.

Tables you can only view

Not every XDR table supports these options. Tables of the XDR table type, such as IdentityInfo, can be viewed but not managed from the Defender portal, while supported integrated tables such as DeviceEvents and AlertInfo become Microsoft Sentinel tables in the workspace once their retention is extended.

In short: the default 30-day hunting window survives every choice, so extend Analytics retention only when Sentinel features need the data hot, and use lake-only ingestion when long, cheap history is the goal.

Log Analytics has a per-table setting of its own, the table plan, and the plan explains why the Defender portal will not edit some tables. It is a different control from the tier and retention settings above: you choose a plan in the Log Analytics workspace under Tables, Manage table, and the Table plan dropdown^[17], while tier and retention are set under Microsoft Sentinel > Configuration > Tables in the Defender portal^[7]. The plan names below are that dropdown's values. A Log Analytics workspace supports three table plans^[17]:

Table plan	Example purpose
Analytics	Continuous monitoring and latency-sensitive analysis
Basic	Troubleshooting and incident response
Auxiliary / Lake (Auxiliary in the Tables API)	High-volume, verbose data kept for long-term, inexpensive storage and aggregated trends

All tables support the Analytics plan, all DCR-based custom tables (custom tables fed through a data collection rule) support every plan, and Azure table support for Basic and Auxiliary / Lake varies by table. Retention works differently too: Basic plan tables have a fixed 30-day query period, while Auxiliary / Lake plan tables can be queried for their whole total retention period^[16], and both have only a total retention setting.

Basic plan tables are managed in Log Analytics

The Defender portal shows Basic plan tables in the Sentinel workspace but manages them only from the Log Analytics workspace^[2]. To manage such a table from the Defender portal, change its plan from Basic to Analytics. Seeing a table in a list is not the same as being able to edit it there.

What a plan switch changes

Table plan updates are limited to one switch per table per week^[17], so a same-day reversal is not a rollback plan. Each direction has consequences:

Switch	Consequences
Basic or Auxiliary / Lake to Analytics	Full Azure Monitor Logs features; cost increases
Analytics to Basic	Queries are billed, including summary rule queries; summary rules that use resource query scope break; total retention is unchanged, but data older than 30 days is treated as long-term retention
Analytics to Auxiliary / Lake	Alerts stop working for the table; queries are billed, including summary rule queries; summary rules that use resource query scope break

Microsoft's plan-switch table warns that summary rules break if the rule uses resource query scope^[17]. In Log Analytics, a query's scope is the set of records it evaluates^[18]: usually all records in one workspace, though it can instead be set to a particular monitored Azure resource. In the Analytics to Basic row, long-term retention is the Log Analytics name for the part of total retention after the query period, a low-cost state in which Analytics and Basic data is reached through search jobs^[16].

A switch never deletes or moves existing data; it changes how the data ingested before the switch is reached. After an Analytics to Auxiliary / Lake switch, older Analytics data stays in the interactive query experience, but a query that spans the switch date can return partial results, so split the time range. After an Auxiliary / Lake to Analytics switch, older Auxiliary / Lake data is not in the interactive experience: reach it with a search job or the search REST API, while newly ingested data is fully interactive. Setting a plan needs workspaces/write and workspaces/tables/write on the workspace, as Log Analytics Contributor provides.

The takeaway: a cheaper plan saves on ingestion but adds query charges and can break alerts or resource-scoped summary rules, so review a table's consumers before you switch it.

A workbook turns query results into an interactive report, and you can start from a template rather than an empty canvas. Sentinel workbooks are based on Azure Monitor workbooks^[3]: each one is an Azure resource whose access Azure RBAC controls, saved in the workspace's resource group and tagged with the workspace it was created in. Working with workbooks needs at least Workbook Reader or Workbook Contributor on that resource group, and creating or deleting them in Sentinel needs Microsoft Sentinel Contributor, or a lesser Sentinel role plus Workbook Contributor (see Task roles beyond the ladder above).

From template to saved workbook

The template path^[3] runs in five steps:

1. Install the solution that contains the workbook, or the workbook as a standalone item, from Content hub.
2. In Sentinel, open Threat management > Workbooks, select the Templates tab, select the template, and check its Required data types field to confirm that data is ingested; installing a workbook does not connect its data sources, so if charts stay empty, check whether the required data is being ingested.
3. Select Save and choose a location. Saving creates an Azure resource from the template; only the workbook's JSON file is saved in that location, and no data, so the logs stay in the workspaces the workbook queries and choosing a save region never moves log data.
4. Select View saved workbook to open it.
5. Select Edit to customize it, use Save as to clone it under another name in the same subscription and resource group, and select Done editing when finished.

Saved workbooks appear on the My workbooks tab. Deleting one permanently removes the workbook resource and its customizations, while the template it came from remains available; templates themselves cannot be deleted. Microsoft's template procedure^[3] starts from a template installed from Content hub, checks its Required data types, and runs through Save, View saved workbook, and Edit, as the figure shows step by step. What to remember: a workbook is a saved definition plus live queries, so its charts are only as complete as the data it queries.

A custom workbook is assembled from components (text, queries, and parameters), and each query component needs a data source, a scope, and a visualization. To start one, select Threat management > Workbooks > Add workbook, then Edit, and add text, queries, and parameters^[3].

Data source and scope

For Sentinel data, set the query's Data source to Logs and its Resource type to Log Analytics, then choose one or more workspaces; the selected workspaces decide which logs the component reads. Logs is one of many workbook data sources^[19], among them a separate Logs (Basic) source for Basic and Auxiliary / Lake plan tables, Metrics, Azure Resource Graph, and Azure Data Explorer. Microsoft Entra ID is not a workbook data source; Entra sign-in and audit data is queried through its Log Analytics tables.

Microsoft recommends querying through an ASIM (Advanced Security Information Model) parser^[20] rather than a built-in table. A parser presents data from many products in one normalized schema, and a unifying parser such as _Im_Dns combines every source normalized to that schema, so a workbook built on it covers current and future sources instead of one vendor's table.

Parameters drive only the components that consume them

A parameter is a workbook control (a time range picker or a resource picker, among others) whose value other components can reference. A time range parameter named TimeRange^[21] reaches a query in one of two ways: select {TimeRange} in the query's Time Range dropdown (a binding), or select Set in query and reference the parameter in the KQL. A resource picker parameter^[22] works the same way: bind it in the query control's resource dropdown, and the query's scope becomes the resources the viewer picks at run time. A selector that no component consumes changes nothing, and every component keeps its own configured time range and scope.

The listing below is a query component built with the settings above, referencing the time parameter in the KQL (the Set in query route). It is the complete query; nothing is cut.

Hourly security event counts, filtered by the workbook's TimeRange parameter

// Query component settings: Data source = Logs, Resource type = Log Analytics
SecurityEvent
| where TimeGenerated {TimeRange}   // the workbook substitutes the picker value, for example > ago(1d)
| summarize Events = count() by bin(TimeGenerated, 1h)   // one time column + one numeric column

The braces in {TimeRange} are workbook parameter syntax, not KQL: the workbook replaces the reference with the parameter's value before the query runs, so the line is not valid KQL outside the workbook. The summarize line returns a time column (TimeGenerated) and a numeric column (Events), the result shape a time-series chart needs.

Match the visualization to the result shape

Workbooks offer charts, grids, tiles, trees, honeycombs, stats, graphs, maps, and text visualizations^[23]. For a chart, set Visualization to Area, Bar, Bar (categorical), Line, Pie, Scatter, or Time. A time-series chart needs time and metric information in the result^[24], so the listing above suits a line chart, while a result of a category column and a count column (for example summarize Events = count() by Computer) suits a categorical bar chart.

The takeaway: a component shows what its own data source, scope, and bindings select, so wire every selector into each component it should control.

Once a workbook is saved, how it refreshes and where it renders decide what its viewers actually see. A workbook refreshes manually with Refresh, or automatically with Auto refresh^[3]:

• Auto refresh intervals range from 5 minutes to 1 day.
• Auto refresh is off by default, and it is turned off again each time you close the workbook, so it never runs in the background.
• It pauses while you edit the workbook, and its interval restarts when you return to view mode or refresh manually.

Auto refresh is a viewing convenience, not monitoring: nothing evaluates the results or raises an alert. Alerting on a condition is the job of a scheduled analytics rule, covered on the Configure detections page.

Where a workbook renders

In the Defender portal, some visualizations can only be viewed in the Azure portal^[3]; select Open in Azure to see them. That limitation is about the portal's rendering support, so rewriting the workbook's query does not fix it. Printing a workbook or saving it as a PDF is also available only in the Azure portal^[3], again through Open in Azure.

Organizing workbooks

Microsoft suggests different workbooks for different uses^[3]: one per persona (a firewall workbook for the network admin) or per review cadence (hourly Microsoft Entra sign-in checks versus daily reviews). For identity data it recommends installing the Microsoft Entra solution and using its Microsoft Entra sign-ins and Microsoft Entra audit logs workbooks.

In short: a workbook is for people looking at data now; scheduled detection and alerting belong in a scheduled analytics rule.

SOC optimization is Sentinel's built-in advisor: it compares what you ingest and detect with what your threats and business risks require, and turns each gap into a recommendation. It uses the standard Sentinel roles and permissions, and using it in the Defender portal requires onboarding Sentinel to the Defender portal^[4]; there, recommendations include coverage from across Microsoft security services. Recommendations come in three families^[25]: data value, coverage, and similar organizations.

Data value recommendations

Data value recommendations improve the ratio of cost to security value for tables, and they look only at billable tables that ingested data in the past 30 days^[25]:

Observation	Suggested action
Not used by analytics rules or detections in the last 30 days, but used by other sources such as workbooks, log queries, or hunting queries	Turn on analytics rule templates, or move the table to the Basic plan if it is eligible
Not used at all in the last 30 days	Turn on analytics rule templates, or stop ingestion and remove the table, or move it to long-term retention
Used only by Azure Monitor	Turn on relevant analytics rule templates for tables with security value, or move the table to a non-security Log Analytics workspace

A table chosen for UEBA (user and entity behavior analytics) or for a threat intelligence matching analytics rule gets no ingestion-change recommendation, because those features give it security value that low rule usage hides. A Preview extension also flags unused columns, such as the ConditionalAccessPolicies column in the SigninLogs or AADNonInteractiveUserSignInLogs table. Microsoft's caution applies to every data value action: confirm that a table is not ingested for compliance or similar reasons before you cut it.

Coverage recommendations

Coverage recommendations add controls where coverage gaps leave you exposed, and come in three kinds:

• Threat-based recommendations analyze your ingested logs and enabled analytics rules, both predefined and user-defined, against the logs and detections a specific type of attack needs.
• AI MITRE ATT&CK tagging recommendations (Preview) use AI to suggest MITRE ATT&CK tactics and techniques for untagged detections; you apply a suggestion to one rule, to all rules in the workspace, or to none.
• Risk-based recommendations (Preview) make the same comparison for scenarios that carry business risk: operational, financial, reputational, compliance, and legal.

Threat-based and risk-based recommendations share one decision table^[25], and it tells you which input is missing:

Observation	Action
Data sources exist, detections are missing	Turn on analytics rule templates, adjusting the name, description, and query logic
Templates are on, data sources are missing	Connect new data sources
Neither detections nor data sources exist	Connect detections and data sources, or install a solution

On the Defender portal Overview tab, the threat-based coverage metric reads High when over 75% of recommended rules are active, Medium at 30% to 74%, and Low at 0% to 29%^[4].

Similar organizations recommendations

Similar organizations recommendations use machine learning to find tables that organizations with similar ingestion trends and industry profiles ingest but you do not, then suggest the data sources and related rules. Microsoft lists four exclusions from them^[25]: custom connectors, custom tables, tables ingested by fewer than 10 workspaces, and tables that contain multiple log sources, such as Syslog and CommonSecurityLog. Not every workspace receives them, and the models never read customer log content; they rely only on organizational identifiable information and system metadata.

The figure below shows the three families and the split inside coverage, with the Preview kinds shaded differently. The takeaway: data value asks whether a table earns its cost, coverage asks whether detections and their data are both present, and similar organizations asks what peers ingest that you lack.

A recommendation is a work item: SOC optimization proposes it, and your team investigates, implements, and closes it. Recommendations are recalculated every 24 hours^[4], and each card shows its status, title, creation date, a short description, and the workspace it applies to.

Acting on a recommendation

Select View details to read the observation behind the recommendation and the value you gain by implementing it. The pane ends with a link to where the change is made: Go to Content Hub when the recommendation adds analytics rules, Change plan when it moves a table to the Basic plan. For threat-based recommendations, spider charts show coverage across tactics and techniques, and View full threat scenario lists the relevant threats with active and recommended detections. If you install only an analytics rule template from Content hub, without installing its solution, that solution shows just the installed template; install the full solution to see all of its content items.

Statuses record progress

A recommendation's status tracks your team's work and changes nothing in the workspace. Statuses start as Active^[4], and the actions in the table below move them; Reactivate, described after the table, moves a completed or dismissed one back:

Action	What it records
Mark as in progress / Mark as active	That someone is working on it (optional; use consistently)
Complete	That every recommended action is done
Dismiss	That you will not act on it; it leaves the list

Active therefore has two uses: it is the status every recommendation starts in, and Microsoft also lists Mark as active beside Mark as in progress as a way to tell teammates you are working on a recommendation, leaving your team to use the two statuses flexibly but consistently^[4].

SOC optimization also completes a recommendation automatically when an environment change makes it irrelevant, for example when a previously unused table is now used by a new analytics rule, and the Overview tab shows a banner counting those. From the Completed or Dismissed tab, Reactivate sends a recommendation back to the Overview tab and recalculates it, which can take up to an hour; a reactivated recommendation that is no longer relevant can move straight to Completed. Selecting Complete never deploys the recommended rule: the change happens only through the linked page.

The figure below traces the status lifecycle. The takeaway: implement through the linked page, then let the status record that you did.

Changing the commitment tier is not one of the three recommendation families: the SOC optimization usage flow lists changing your commitment tier for cost savings^[4] as an action to consider, beside adding analytics rules, once recommendations reveal low-usage tables. A commitment tier is a pricing agreement for Analytics tier data that starts at 100 GB per day^[15], as the alternative to pay-as-you-go. It is billed daily; you can increase it anytime, which restarts the 31-day commitment period, but moving to a lower tier or back to pay-as-you-go must wait until that period finishes^[26], and changing it requires the Azure Contributor or Azure Owner role on the workspace. A commitment tier changes the price of ingestion, not what is collected, how long it is kept, or which plan a table uses, so it never removes a detection's input.

Table insights answers a narrower question than SOC optimization: is each table receiving the data you expect, and at what estimated cost? It is a built-in monitoring view on the Defender portal Tables page^[7] for the selected Sentinel workspace, including tables that third-party data connectors populate. Its signals include:

Signal	What it shows
Ingestion volume per tier	Rolling 30-day GB ingested into the Analytics and Data Lake tiers
Table ingestion fluctuations	Tables whose last 24 hours differ from the same day last week by at least the configured threshold
Top 5 tables by daily ingestion volume	The main ingestion drivers over the last 30 days
Last data received	Time since the table last received a record
Avg. daily ingestion	Average GB per day over the lookback window
Est. daily ingestion cost	Estimated daily ingestion cost at the table's current tier
Volume anomaly	Signed percentage change from the baseline ingestion pattern

Use these signals to spot a connector that went silent, explain a cost spike, confirm that a newly onboarded connector lands on the expected tier, and find tables whose tier or retention could be right-sized. When detections suddenly drop, a table showing a 100 percent decrease is the first place to look.

Limits and permissions

Table insights is a visualization surface for investigation, not a billing-grade or alerting surface^[2]. The documented limitations^[7] explain why:

• The cost estimate uses the public list price for the tier and region, without commitment-tier discounts, reservations, or private pricing.
• Fluctuations need at least a 10 percent and 1 MB change by default, and tables under 1 MB per day are not evaluated at all.
• Volume cards cover only the last 30 days, and the view shows one workspace at a time.
• To alert on table health, you create a scheduled analytics rule that uses the SentinelHealth table or a KQL query against Usage.

Viewing Table insights needs Microsoft Sentinel Reader on the workspace's resource group; configuring fluctuation thresholds needs Microsoft Sentinel Contributor, and changing a table's tier or retention from it needs Microsoft Sentinel Contributor plus Log Analytics Contributor. These are the minimum roles Microsoft lists for working from Table insights^[7]; the general Tables-page requirement for viewing and configuring table settings is the one in Changing table settings is data management above.

What to remember: Table insights diagnoses ingestion, while your Azure bill and your analytics rules stay the authorities for cost and alerting.

To practice, take a person, a table, or a dashboard and choose the setting that fits it best, whether a role (such as a Microsoft Sentinel built-in role^[1], or an Azure or Microsoft Entra ID role of the kind Microsoft adds for specific tasks^[1]), a table's tier, retention, or plan, a workbook setting, or a SOC optimization action; then explain why a real feature applied to the wrong job would not fit. Each row of the table below restates one pattern in one line, such as Microsoft's recommendation to give security analysts Microsoft Sentinel Responder^[1], and the section title in parentheses names where this page explains it.

Requirement or symptom	Role, table setting, workbook setting, or SOC optimization action	Why the alternative falls short
Analyst must manage incidents but not edit rules	Microsoft Sentinel Responder	Microsoft Sentinel Contributor also allows content changes (Reader, Responder, Contributor: the SIEM role ladder)
Engineer must edit analytics rules and install solutions	Microsoft Sentinel Contributor	Responder stops at incident management (Reader, Responder, Contributor: the SIEM role ladder)
Analyst must run existing playbooks manually	Microsoft Sentinel Playbook Operator	Logic App Contributor also allows editing workflows, and Sentinel Contributor cannot run playbooks (Task roles beyond the ladder)
Engineer must change a playbook's steps	Logic App Contributor	Playbook Operator only lists, views, and runs (Task roles beyond the ladder)
Guest analyst cannot assign incidents	Directory Readers (Microsoft Entra ID) plus Responder	Upgrading to Contributor adds SIEM rights but no directory lookup (Task roles beyond the ladder)
Dashboard author must not touch rules	Reader or Responder plus Workbook Contributor	Contributor also grants unrelated content changes (Task roles beyond the ladder)
Least privilege fails although Reader was added	Remove the broader assignment	Assignments are cumulative, so Reader restricts nothing (Reader, Responder, Contributor: the SIEM role ladder)
Analyst sees incidents but not the playbooks	Assign at the resource group	A workspace-only assignment misses the Logic Apps (Assigning Sentinel roles at the resource group)
Team must read one lake workspace only	A workspace-scoped role such as Log Analytics Reader	A tenant-wide Entra role such as Security Reader opens every lake workspace (Microsoft Sentinel data lake permissions)
User must schedule data lake jobs	Security Operator	Security Reader is read-only; administrator roles are broader than needed (Microsoft Sentinel data lake permissions)
Server owners need only their servers' logs	Resource-context RBAC	A workbook filter does not restrict direct queries (Restricting access to part of a workspace)
Ten years of history, short hot window	Short Analytics retention, total retention up to 12 years	Analytics retention tops out at two years (Analytics retention and total retention)
Cut cost on a table that rules depend on	Keep it in the Analytics tier and reduce collection only after validating that its rules retain their required inputs	The Data Lake tier stops analytics rules and alerting on it (Analytics, Data Lake, and XDR default tiers)
Total retention was shortened by mistake	Revert within the 30-day wait	Lengthening retention after removal recovers nothing (Analytics retention and total retention)
Keep XDR data 90 days for Sentinel rules	Extend Analytics retention for supported tables, budgeting ingestion	Free storage does not cover Sentinel ingestion charges (Defender XDR tables in Sentinel's tiers)
Basic plan table will not change in Defender	Manage it in Log Analytics, or switch it to Analytics	Visibility in the Defender list is not editability (Log Analytics table plans and plan switches)
Workbook template shows empty charts	Ingest its Required data types	Reinstalling the template connects no data (Building a workbook from a Content hub template)
Time picker does not change a chart	Bind the component to {TimeRange} or reference it in the query	The selector alone changes nothing (Building a custom workbook query)
Visualization will not render in the Defender portal	Open in Azure	Rewriting the query adds no rendering support (Viewing and refreshing workbooks)
Recommendation: templates are on, data is missing	Connect the missing data sources	More rule templates still have no input (SOC optimization recommendation types)
Recommendation marked Complete	Records status only	It does not create or enable the rule (Working a SOC optimization recommendation)
Usage flow suggests changing the commitment tier	Adjust the pricing tier	Shortening retention changes history, not ingestion pricing (Changing the commitment tier)

The takeaway: identify the job first (view, respond, author, run, store, display, or tune), then pick the narrowest setting that covers exactly that job.