> For the complete documentation index, see [llms.txt](https://docs.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vectra.ai/configuration/response/siem/microsoft-defender-xdr-codeless-connector-framework-rux.md).

# Microsoft Defender XDR Codeless Connector Framework (RUX)

### Overview

The Microsoft Defender portal is Microsoft's unified security operations platform, bringing together SIEM, XDR, threat intelligence, and exposure management in a single interface. When Microsoft Sentinel is connected to the Defender portal, all security data — including Vectra AI detections — flows into a unified incident queue, a shared Advanced Hunting environment, and cross-platform workbooks and analytics, eliminating the need to work across separate tools during an investigation.

This document describes how to deploy and configure the Vectra AI RUX Security Data Connector for use within the Microsoft Defender portal. The connector ingests detection, entity, and lockdown telemetry from the Vectra AI platform and makes it immediately available across the full Defender XDR experience: the unified incident queue, Advanced Hunting (where Vectra data can be correlated against Defender endpoint, identity, and cloud signals), workbooks, analytics rules, and SOAR playbooks.

The connector is built on the Vectra AI RUX API and the Microsoft Sentinel Codeless Connector Framework (CCF). It does not require an Azure Function App, virtual machine, or customer-managed compute. Data polling, transformation, and ingestion are handled natively by Microsoft Sentinel through CCF and Data Collection Rules (DCRs), with all results surfaced directly in the Defender portal.

The solution package includes:

* Data Connector
* Parsers
* Custom Log Analytics tables
* Workbook template
* Analytics rule templates
* Playbooks / Logic Apps

> **Note on the underlying platform:** Microsoft Sentinel provides the ingestion infrastructure for this integration. A Sentinel-enabled Log Analytics workspace must be connected to the Defender portal before deploying this connector. This is a one-time setup covered in the Prerequisites section. Once connected, all configuration and day-to-day operation is performed entirely within the Defender portal.

> **Note on Azure portal retirement:** After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available exclusively in the Microsoft Defender portal. All customers are encouraged to connect their Sentinel workspace to the Defender portal now.

**Architecture**

```
Vectra AI (RUX) Platform
        │
        │ < HTTPS polling via Microsoft Sentinel CCF >
        │
Microsoft Sentinel / Log Analytics Workspace
        │
        ├── Custom Tables
        │   ├── Detections_Data_CCF_CL
        │   ├── Entities_Data_CCF_CL
        │   └── Lockdown_Data_CCF_CL
        │
        ├── Parsers
        │   ├── VectraRUXDetections
        │   ├── VectraDetectionsCombined
        │   ├── VectraEntities
        │   └── VectraLockdown
        │
        ├── Workbook Template
        │   └── VectraRUXSecurityDashboard
        │   └── VectraRUXTimelineWorkbook
        │
        ├── Analytics Rule Templates
        │   ├── Account incident rule
        │   └── Host incident rule
        │
        └── Playbooks / Logic Apps
```

**Connector Components**

<table><thead><tr><th width="213">Component</th><th>Description</th></tr></thead><tbody><tr><td>Data Connector</td><td>Registers and configures the Vectra RUX connector in Microsoft Sentinel</td></tr><tr><td>Data Collection Rules</td><td>Define ingestion streams, transformations, and table mappings</td></tr><tr><td>Custom Tables</td><td>Store detections, entities, and lockdown records</td></tr><tr><td>Parsers</td><td>Provide normalized KQL functions for querying Vectra data</td></tr><tr><td>Workbook Template</td><td>Provides the Vectra RUX Security Dashboard and the Detection Timeline investigation workbook</td></tr><tr><td>Analytics Rule Templates</td><td>Provide incident creation rules for host and account detections</td></tr><tr><td>Playbooks / Logic Apps</td><td>Provide automation actions for enrichment, tagging, notes, assignments, and response workflows</td></tr></tbody></table>

### Prerequisites

**1. Microsoft Sentinel Workspace**

A Log Analytics workspace with Microsoft Sentinel enabled is required. The connector is deployed into this workspace and its data flows into the custom tables described in this document.

**2. Connect Microsoft Sentinel to the Defender Portal**

If your Sentinel workspace is not yet connected to the Microsoft Defender portal, complete the following steps before proceeding with connector installation.

**Required permissions for onboarding:**

* Microsoft Entra ID: **Security Administrator** role
* Azure: **Owner** (unconditional role assignment at subscription scope) — or — **User Access Administrator** + **Microsoft Sentinel Contributor**

**Steps to connect:**

1. Go to the [Microsoft Defender portal](https://security.microsoft.com/) and sign in.
2. In the left navigation, select **System** > **Settings** > **Microsoft Sentinel**.
3. Select **Connect a workspace**.
4. Select the Log Analytics workspace that has Microsoft Sentinel enabled.
5. Select **Next**, then designate the **Primary workspace**.
6. Review the product change summary and select **Connect**.

After the workspace connects, a **Microsoft Sentinel** section appears in the left navigation pane and the Defender portal Home page displays Sentinel metrics such as the number of active data connectors and automation rules.

> **Note:** Customers who onboarded to Microsoft Sentinel after July 1, 2025 may already be connected to the Defender portal automatically.

**3. Vectra API Credentials**

Create one dedicated API client in the Vectra AI platform for each data stream. Each client requires a Client ID and Client Secret with read-only scope. Recommended naming:

<table><thead><tr><th width="270.3515625">Stream</th><th>Recommended API Client Name</th></tr></thead><tbody><tr><td>Detections</td><td>Defender-Detections (read-only)</td></tr><tr><td>Entities</td><td>Defender-Entities (read-only)</td></tr><tr><td>Lockdown</td><td>Defender-Lockdown (read-only)</td></tr></tbody></table>

### Deployment

The connector supports two deployment modes depending on certification status.

**Preview Deployment**

During preview, customers deploy the solution using **Deploy a custom template** in the Azure portal using a JSON ARM template provided by Vectra. The ARM template includes the full Microsoft Sentinel solution package: Data Connector, Parsers, Custom Log Analytics tables, Workbook template, Analytics rule templates, and Playbooks / Logic Apps.

After ARM template deployment, the connector is configured from the Microsoft Defender portal as described in the Installation & Configuration section.

**Content Hub Deployment**

After certification, deployment is performed through **Microsoft Sentinel Content Hub**, accessible from the Defender portal. Customers install the Vectra RUX solution from Content Hub, then configure the connector, enable analytics rule templates, save the workbook template, and configure playbooks.

### Data Connector

The connector polls the Vectra RUX API using OAuth2 client credentials. Each connection requires a connection alias, Vectra API base URL, Client ID, Client Secret, and the selected data stream.

A **Data Stream** is an individual ingestion pipeline within the connector that retrieves a specific category of data from the Vectra RUX API and writes it into a corresponding Log Analytics table. Each stream operates independently and defines the API endpoint being queried, the polling interval, the checkpoint or synchronization method, the target Log Analytics table, and the associated parser and transformation logic.

The three data streams within the Security Operations integration are:

<table><thead><tr><th width="106">Stream</th><th width="216">Official Table</th><th width="192">Parser</th><th width="243">Checkpoint Method</th><th>Poll Interval</th></tr></thead><tbody><tr><td>Detections</td><td>Detections_Data_CCF_CL</td><td>VectraRUXDetections</td><td>PersistentToken using next_checkpoint</td><td>5 minutes</td></tr><tr><td>Entities</td><td>Entities_Data_CCF_CL</td><td>VectraEntities</td><td>Sliding window using last_modified_timestamp_gte</td><td>10 minutes</td></tr><tr><td>Lockdown</td><td>Lockdown_Data_CCF_CL</td><td>VectraLockdown</td><td>Snapshot</td><td>5 minutes</td></tr></tbody></table>

> **Note:** The previous Log Ingestion API (package version 3.3.0) uses table names without \_CCF (example: Detections\_Data\_CL). These tables are joined when populating the workbook to provide a better experience during the migration period after deploying this CCF version of the integration.

**Detections Stream**

The detections stream uses an event-based checkpointing model built around the Vectra `/events/detections` API endpoint. Each detection event in Vectra is assigned a serialized event ID. As new events occur, the ID increments monotonically.

After each successful polling cycle, events are ingested into `Detections_Data_CCF_CL` and the highest processed event ID is stored as the checkpoint. The next polling cycle resumes from that checkpoint, ensuring the connector always continues from the exact point where the previous ingestion cycle ended.

Because the checkpoint is ID-based rather than time-based:

* Poll timing does not affect data continuity
* Connector restarts do not cause gaps
* Temporary outages do not lose events
* Clock drift issues are avoided

Even if the connector does not poll again for several minutes, hours, or days, the next poll will continue from the last processed detection event ID.

**Detection Polling Example**

```
Initial checkpoint: 105000

Poll #1:
  Retrieves events 105001 → 105250
  Stores checkpoint 105250

Poll #2:
  Retrieves events 105251 → 105400
  Stores checkpoint 105400
```

**Determining the Detections Starting Checkpoint Seed Value**

When the connector is initially configured, a starting event ID must be provided. The connector requests all events occurring after that ID. The recommended approach depends on the deployment type.

<table><thead><tr><th width="240">Term</th><th>Meaning</th></tr></thead><tbody><tr><td>Greenfield Deployment</td><td>No prior Vectra integration exists in Sentinel</td></tr><tr><td>Migration Deployment</td><td>A prior Vectra integration already exists and the customer is transitioning to the CCF connector</td></tr></tbody></table>

*Greenfield Deployments* — An API call to the Vectra platform is required to determine the seed value:

```
GET <vectraApiUrl>/api/v3.5/events/detections?limit=1&ordering=-id
```

Copy the returned `next_checkpoint` value into the detections starting checkpoint field.

*Migration Deployments* — When a previous integration exists, the most recent event retrieved from Vectra is available via KQL in Advanced Hunting:

```kql
Detections_Data_CL
| summarize checkpoint = max(id)
```

> **Note:** This query intentionally references the old table name `Detections_Data_CL`, as the previous integration has already populated data to a known point and the new connector should pick up from there.

**Entities Stream**

The entities stream uses time-based polling. The connector polls the Vectra entities endpoint every 10 minutes and retrieves entities modified since the previous polling window, using `current_time - 10 minutes` as the value for `last_modified_timestamp_gte`.

**Example:**

```
Current poll time: 14:00 UTC
Query parameter:   last_modified_timestamp_gte = 13:50 UTC
```

The entities stream continuously captures entity score changes, priority changes, assignment changes, state changes, tag updates, and entity metadata changes. Both host and account entities are included automatically.

Because the entities stream is time-window based, it does not maintain a serialized checkpoint and data continuity depends on successful polling intervals. Small overlap windows help reduce the chance of missed updates. This model is appropriate because entities represent continuously changing state (cumulative) rather than immutable event records.

**Lockdown Stream**

The lockdown stream uses a snapshot polling model. Every 5 minutes, the connector queries the current lockdown state from the Vectra API. If active lockdown records are returned, they are ingested into `Lockdown_Data_CCF_CL`.

The lockdown stream does not maintain a checkpoint because the API represents current state rather than historical events.

**Important behavior:** There is intentionally no post-processing deduplication for lockdown records. If an entity remains locked down for an extended period of time, the same lockdown record will be retrieved and ingested during every polling interval while the lockdown remains active.

<table><thead><tr><th width="159">Time</th><th>Result</th></tr></thead><tbody><tr><td>12:00</td><td>Entity locked down</td></tr><tr><td>12:05</td><td>Same lockdown record ingested</td></tr><tr><td>12:10</td><td>Same lockdown record ingested</td></tr><tr><td>12:15</td><td>Same lockdown record ingested</td></tr></tbody></table>

This behavior is intentional. Repeated ingestion provides an operational audit trail showing that the entity remained continuously locked down throughout the observed period, and also allows operators to identify situations where a lockdown was manually removed, temporarily disappeared, or reinstated later. Because the stream represents observed state over time rather than unique events, duplicate records are expected behavior.

When evaluating current lockdown state, filter to recent records using Advanced Hunting:

```kql
Lockdown_Data_CCF_CL
| where TimeGenerated > ago(15m)
```

To analyze historical lockdown continuity, query the full table without deduplication.

**Parsers**

Use the included parsers for workbooks, analytics rules, hunting, and operational queries rather than querying the raw tables directly.

<table><thead><tr><th width="234">Parser</th><th>Source Table</th><th>Purpose</th></tr></thead><tbody><tr><td>VectraRUXDetections</td><td>Detections_Data_CCF_CL</td><td>Normalized detection data</td></tr><tr><td>VectraDetectionsCombined</td><td>Detections_Data_CL<br>Detections_Data_CCF_CL</td><td>Normalized detection data combining previous deployments</td></tr><tr><td>VectraEntities</td><td>Entities_Data_CCF_CL</td><td>Normalized entity data</td></tr><tr><td>VectraLockdown</td><td>Lockdown_Data_CCF_CL</td><td>Normalized lockdown data</td></tr></tbody></table>

**Recommended:**

```kql
VectraRUXDetections
| take 10
```

**Deduplication Guidance**

Detection records may contain multiple updates for the same detection ID. Use `arg_max()` to evaluate the latest known state:

```kql
VectraRUXDetections
| summarize arg_max(TimeGenerated, *) by ["Detection ID"]
```

### Installation & Configuration

**Installing the Connector**

**Preview Installation (ARM Template)**

The ARM template is deployed via the Azure portal. After deployment, all configuration is performed in the Microsoft Defender portal.

1. Open the [Azure portal](https://portal.azure.com/).
2. Search for **Deploy a custom template**.
3. Select **Build your own template in the editor**.
4. Paste or upload the provided Vectra RUX ARM template.
5. Select the subscription, resource group, and Sentinel workspace.
6. Deploy the template.
7. Open the [Microsoft Defender portal](https://security.microsoft.com/).
8. In the left navigation, go to **Microsoft Sentinel** > **Configuration** > **Data connectors**.
9. Search for **Vectra RUX Security Data Connector** and open it.
10. Add one connection per data stream: Detections, Entities, Lockdown.

**Content Hub Installation**

1. Open the [Microsoft Defender portal](https://security.microsoft.com/).
2. In the left navigation, go to **Microsoft Sentinel** > **Content management** > **Content hub**.
3. Search for **Vectra RUX** and select the solution.
4. Select **Install**.
5. After installation completes, navigate to **Microsoft Sentinel** > **Configuration** > **Data connectors**.
6. Open the **Vectra RUX Security Data Connector** and configure the connector connections.
7. Enable analytics rule templates (see Analytics Rules).
8. Save the workbook template if required (see Workbooks).
9. Configure playbooks and automation rules as needed (see Playbooks).

**Connector Configuration**

A separate Vectra API client is recommended for each data stream to avoid OAuth2 rate limiting.

**Configuring a connection:**

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Data connectors**.
2. Search for and open the **Vectra RUX Security Data Connector**.
3. Select **Open connector page**.
4. Under **Configuration**, select **Add connection**.
5. Enter the following for each data stream:

<table><thead><tr><th width="283.64453125">Field</th><th>Value</th></tr></thead><tbody><tr><td>Connection Alias</td><td>A descriptive name (e.g., <code>Vectra-Detections</code>, <code>Vectra-Entities</code>, <code>Vectra-Lockdown</code>)</td></tr><tr><td>Vectra API Base URL</td><td>Your Vectra platform URL (e.g., <code>https://&#x3C;your-brain>.portal.vectra.ai</code>)</td></tr><tr><td>Client ID</td><td>OAuth2 Client ID from the Vectra API client</td></tr><tr><td>Client Secret</td><td>OAuth2 Client Secret from the Vectra API client</td></tr><tr><td>Data Stream</td><td>Select: Detections, Entities, or Lockdown</td></tr><tr><td>Detections Starting Checkpoint</td><td>(Detections stream only) The seed event ID (see checkpoint guidance above)</td></tr></tbody></table>

6. Select **Connect**.
7. Wait at least **one minute** before adding the next stream connection to avoid OAuth2 API rate limiting.

Repeat for each of the three streams: Detections, Entities, and Lockdown.

**Verifying Data Flow**

After 10–15 minutes, verify ingestion using Advanced Hunting.

1. In the Defender portal, go to **Investigation & response** > **Hunting** > **Advanced hunting**.
2. Run the following queries to confirm data is arriving.

**Raw table verification:**

```kql
Detections_Data_CCF_CL | take 10
Entities_Data_CCF_CL   | take 10
Lockdown_Data_CCF_CL   | take 10
```

**Parser validation:**

```kql
VectraRUXDetections      | take 10
VectraDetectionsCombined | take 10
VectraEntities           | take 10
VectraLockdown           | take 10
```

**Monitoring Connector Health**

Microsoft Sentinel connector health is written to the `SentinelHealth` table when auditing and health monitoring is enabled.

> **Note:** The CCF-based connector does not use Azure Function Apps and therefore does not generate Function App telemetry or Application Insights exceptions. Connector health should be monitored using Microsoft Sentinel's native connector health capabilities.

**Enabling Health Monitoring**

1. In the Defender portal, go to **System** > **Settings** > **Microsoft Sentinel**.
2. Select **Settings**.
3. Select **Auditing and health monitoring**.
4. Select one of the following options:

<table><thead><tr><th width="275">Option</th><th>Description</th></tr></thead><tbody><tr><td>Enable</td><td>Enables auditing and health monitoring for all supported Sentinel resource types</td></tr><tr><td>Configure diagnostic settings</td><td>Allows granular selection of monitored resource categories and destinations</td></tr></tbody></table>

For most deployments, selecting **Enable** is recommended. Microsoft Sentinel automatically creates the required diagnostic settings and begins sending health telemetry to the Log Analytics workspace.

> **Note:** The `SentinelHealth` table is created automatically after the first health event is generated. This can take up to 30 minutes.

Verify the table is available using Advanced Hunting:

```kql
SentinelHealth | take 20
```

**Recommended Connector Health Query**

Returns the latest health state for the Vectra connector streams, filtered to failures only. Run this in **Advanced Hunting** for ad-hoc troubleshooting:

```kql
SentinelHealth
| where TimeGenerated > ago(24h)
| where SentinelResourceType == "Data connector"
| extend DestinationTable = tostring(ExtendedProperties.DestinationTable)
| extend StreamName = tostring(ExtendedProperties.StreamName)
| where DestinationTable in (
    "Detections_Data_CCF_CL",
    "Entities_Data_CCF_CL",
    "Lockdown_Data_CCF_CL"
  )
  or StreamName has_any (
    "Detections_Data_CCF_CL",
    "Entities_Data_CCF_CL",
    "Lockdown_Data_CCF_CL"
  )
| summarize arg_max(TimeGenerated, *) by DestinationTable
| project
    TimeGenerated,
    SentinelResourceName,
    DestinationTable,
    StreamName,
    Status,
    Description,
    Reason
| where Status != "Success"
| order by TimeGenerated desc
```

No results means there are no errors. Comment out the `Status != "Success"` line to review successful events as well.

**Recommended Health Monitoring Alert Rule**

Create a Scheduled Analytics Rule in Microsoft Sentinel to alert on connector failures.

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Analytics**.
2. Select **Create** > **Scheduled query rule**.
3. Configure using the following settings:

<table><thead><tr><th width="255.53125">Setting</th><th>Recommended Value</th></tr></thead><tbody><tr><td>Rule Type</td><td>Scheduled</td></tr><tr><td>Query Frequency</td><td>15 minutes</td></tr><tr><td>Query Period</td><td>30 minutes</td></tr><tr><td>Trigger Threshold</td><td>Greater than 0</td></tr><tr><td>Severity</td><td>Medium</td></tr><tr><td>Incident Creation</td><td>Enabled</td></tr></tbody></table>

```kql
SentinelHealth
| where TimeGenerated > ago(30m)
| where SentinelResourceType == "Data connector"
| extend DestinationTable = tostring(ExtendedProperties.DestinationTable)
| where DestinationTable in (
    "Detections_Data_CCF_CL",
    "Entities_Data_CCF_CL",
    "Lockdown_Data_CCF_CL"
  )
| where Status != "Success"
```

Microsoft also provides the **Data collection health monitoring** workbook through Content Hub, which visualizes connector ingestion trends, anomalies, and connector health state over time. Install it from: **Microsoft Sentinel** > **Content management** > **Content hub** > search **Data collection health monitoring**.

### Advanced Hunting

Advanced Hunting in the Defender portal provides a unified KQL query interface across both Microsoft Sentinel tables and Defender XDR data. Vectra detection, entity, and lockdown data is immediately available alongside native Defender XDR telemetry — enabling cross-platform correlation without context switching.

**Accessing Advanced Hunting:**

1. In the Defender portal, go to **Investigation & response** > **Hunting** > **Advanced hunting**.

**Example: Surface prioritized Vectra detections with Defender XDR device context**

```kql
VectraRUXDetections
| summarize arg_max(TimeGenerated, *) by ["Detection ID"]
| where ["Unresolved Priority"] == true
| join kind=leftouter (
    DeviceInfo
    | project DeviceName, OSPlatform, PublicIP
  ) on $left.["Source IP"] == $right.PublicIP
| project
    ["Detection ID"],
    ["D Type Vname"],
    ["Detection Category"],
    ["Entity Name"],
    ["Source IP"],
    DeviceName,
    OSPlatform,
    ["Investigation Status"],
    TimeGenerated
```

**Using Security Copilot in Advanced Hunting**

The Defender portal includes Security Copilot embedded in Advanced Hunting. Analysts can describe what they want to find in natural language and Security Copilot will generate a KQL query. For Vectra data, this works best with specific prompts such as:

* "Show me all Vectra detections with unresolved priority from the last 24 hours"
* "Find Vectra entity records where urgency score is above 50 and the entity is prioritized"
* "Show Vectra lockdown events from the last hour"

### Workbooks

**VectraRUXSecurityDashboard**

The solution includes the **VectraRUXSecurityDashboard** workbook template, which provides visibility into entity scoring and prioritization, detection activity, escalated and prioritized detections, MITRE ATT\&CK mappings, data source classification, lockdown state, entity-to-detection drilldowns, and deep links into Vectra.

**Workbook Tabs & Filters**

<table><thead><tr><th width="149">Tab</th><th>Description</th></tr></thead><tbody><tr><td>Entity</td><td>Entity priority, urgency, scoring, assignment, and drilldown views</td></tr><tr><td>Detections</td><td>Detection investigation, category counts, MITRE filtering, and selected detection details</td></tr><tr><td>Lockdown</td><td>Lockdown status by entity, lock timestamp, unlock timestamp, and locking user</td></tr></tbody></table>

The workbook includes filters for time range, prioritized status, entity type, data source type, detection category, detection behavior, MITRE technique, and lockdown status. Supported data source categories include AWS, Azure, Entra ID/M365, and Network.

**Detection Timeline Workbook**

The solution also includes the **VectraDetectionTimeline** workbook, a SOC-focused investigation workbook that shows the full event lifecycle of an individual Vectra detection — from initial creation through every evidence addition (`append`), context change (`adjust`), investigation status update, and eventual closure.

The workbook is designed to be used alongside the Vectra RUX Security Dashboard. Once an incident is opened in the Defender portal, analysts use the Detection Timeline to trace the complete history of the underlying detection and review how evidence evolved over time.

<table><thead><tr><th width="224">Panel</th><th>Description</th></tr></thead><tbody><tr><td>Detection Summary</td><td>Pivot table showing all detections in the selected time range. Columns include entity, category, priority, first seen, latest update, event counts, assignment, and a direct Vectra link. Click any row to scope all lower panels to that detection.</td></tr><tr><td>Full Timeline</td><td>Chronological event log across all change types for the selected detection.</td></tr><tr><td>New Detection</td><td>Details for the initial detection event, including source/destination host and account names, destination domain, and expandable summary and detail views.</td></tr><tr><td>Evidence Appends</td><td>Details for each subsequent evidence addition, with the same field set as the New Detection panel.</td></tr><tr><td>Context Adjustments</td><td>Records of context-only changes such as tag updates, assignment changes, and external reference updates.</td></tr><tr><td>Investigation Status</td><td>Log of investigation status transitions.</td></tr><tr><td>State / Close</td><td>State and closure events with closure reason.</td></tr><tr><td>Triage</td><td>Triage activity records.</td></tr><tr><td>Linked Incidents</td><td>Sentinel incidents linked to the selected detection (visible when a Detection ID is selected).</td></tr></tbody></table>

**Filters:** Time Range, Detection ID (text or click-to-set), Entity ID, and Change Type (multi-select; applies to Detection Summary and Full Timeline panels).

**Integration with VectraRUX-DetectionTimeline-Link playbook** — A companion playbook automatically posts a comment on each new Sentinel incident containing the detection ID and a direct link to the Detection Timeline workbook, allowing analysts to navigate into the pre-filtered view without manual lookup.

**Opening and Saving Workbooks**

**To view the workbook:**

1. In the Defender portal, go to **Microsoft Sentinel** > **Threat management** > **Workbooks**.
2. Select the **Templates** tab.
3. Search for `VectraRUXSecurityDashboard` or `VectraRUXTimelineWorkbook`.
4. Select the workbook and choose **View template**.

**To save the workbook to My workbooks:**

1. Open the workbook from Templates.
2. Select **Save**.
3. Choose the subscription, resource group, and region.
4. Save the workbook.

### Analytics Rules

The solution includes two Scheduled analytics rule templates — both rules should be enabled. These analytic rules create incidents for any detection that is prioritized (`unresolved_priority = true`) or has been manually escalated, regardless of priority. Two separate rules are required to ensure accurate entity mapping within Sentinel: hosts map to hostname, accounts map to username.

Incidents created by these rules appear in the unified incident queue at **Investigation & response** > **Incidents & alerts** > **Incidents**, alongside all other Defender XDR incidents.

<table><thead><tr><th width="399">Rule Template</th><th>Purpose</th></tr></thead><tbody><tr><td>Vectra RUX - Create Incident for Escalated Host Detection or Unresolved Priority Host</td><td>Creates incidents for host detections that are escalated or unresolved priority</td></tr><tr><td>Vectra RUX - Create Incident for Escalated Account Detection or Unresolved Priority Account</td><td>Creates incidents for account detections that are escalated or unresolved priority</td></tr></tbody></table>

**Rule Logic & Queries**

**Trigger condition** — An incident is created when either condition is true:

```
Investigation Status == "escalated"
OR
Unresolved Priority == true
```

**Shared rule configuration:**

| Setting                    | Value                |
| -------------------------- | -------------------- |
| Rule type                  | Scheduled            |
| Enabled by default         | No                   |
| Severity                   | High                 |
| Query frequency            | 10 minutes           |
| Query period               | 10 minutes           |
| Trigger operator           | Greater than         |
| Trigger threshold          | 0                    |
| Event grouping             | One alert per result |
| Incident creation          | Enabled              |
| Incident grouping lookback | 7 days               |
| Reopen closed incidents    | False                |

**Host Rule Query:**

```kql
VectraRUXDetections
| where ["Entity Type"] == "host"
| summarize arg_max(TimeGenerated, *) by ["Detection ID"]
| where ["Investigation Status"] == "escalated" or ["Unresolved Priority"] == true
| extend
    detection_name       = ["D Type Vname"],
    detection_category   = ["Detection Category"],
    entity_url           = replace_string(replace_string(URL, "api/v3.4/", ""), "api/v3.5/", ""),
    mitre_techniques     = tostring(Mitre),
    detection_tags       = tostring(Tags),
    assigned_to          = ["Assigned To"],
    entity_name          = ["Entity Name"],
    entity_uid           = ["Entity UID"],
    entity_id            = ["Entity ID"],
    detection_id         = ["Detection ID"],
    external_reference   = ["External Reference"],
    investigation_status = ["Investigation Status"],
    entity_type          = ["Entity Type"]
```

**Account Rule Query:**

```kql
VectraRUXDetections
| where ["Entity Type"] == "account"
| summarize arg_max(TimeGenerated, *) by ["Detection ID"]
| where ["Investigation Status"] == "escalated" or ["Unresolved Priority"] == true
| extend
    detection_name       = ["D Type Vname"],
    detection_category   = ["Detection Category"],
    entity_url           = replace_string(replace_string(URL, "api/v3.4/", ""), "api/v3.5/", ""),
    mitre_techniques     = tostring(Mitre),
    detection_tags       = tostring(Tags),
    assigned_to          = ["Assigned To"],
    entity_name          = ["Entity Name"],
    entity_uid           = ["Entity UID"],
    entity_id            = ["Entity ID"],
    detection_id         = ["Detection ID"],
    external_reference   = ["External Reference"],
    investigation_status = ["Investigation Status"],
    entity_type          = ["Entity Type"]
```

**Entity Mapping:**

<table><thead><tr><th width="190">Rule</th><th width="178">Sentinel Entity Type</th><th>Mapping</th></tr></thead><tbody><tr><td>Host rule</td><td>Host</td><td>HostName → entity_name</td></tr><tr><td>Account rule</td><td>Account</td><td>Name → entity_name, UPNSuffix → entity_uid</td></tr></tbody></table>

**Custom Alert Details** — Each alert includes the following details extracted from Vectra: Detection ID, Detection Name, Detection Category, Entity ID, Entity UID, Entity URL, Entity Type, Tags, Assigned To, Investigation Status, External Reference, and MITRE Techniques.

**Enabling Analytics Rules**

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Analytics**.
2. Select the **Rule templates** tab.
3. Search for `Vectra RUX`.
4. Select each Vectra RUX rule template.
5. Select **Create rule**, review the configuration, and enable the rule.

**Viewing Incidents**

Incidents generated by the Vectra analytics rules appear in the unified incident queue alongside Defender XDR incidents.

1. In the Defender portal, go to **Investigation & response** > **Incidents & alerts** > **Incidents**.
2. Use the filter options to narrow by source, severity, or status.
3. Vectra incidents include all custom alert details (Detection ID, Entity URL, MITRE Techniques, etc.) and are linked to host or account entity pages for further investigation.

When the **VectraRUX-DetectionTimeline-Link** playbook is configured and attached via an automation rule, each Vectra incident will include a comment with a direct link to the Detection Timeline workbook pre-filtered to the relevant detection.

### Playbooks

The Vectra RUX solution includes several Microsoft Sentinel playbooks implemented as Azure Logic Apps. These playbooks extend SOAR capabilities, allowing analysts and automation workflows to interact directly with the Vectra AI platform for detection triage, entity management, assignment workflows, tagging, timeline synchronization, and PCAP evidence collection. The playbooks are connector-agnostic and work whether detections are ingested via the CCF connector or the legacy Function App connector.

**Playbook Categories**

<table><thead><tr><th width="227">Category</th><th>Purpose</th></tr></thead><tbody><tr><td>Authentication</td><td>Generate and manage OAuth tokens</td></tr><tr><td>Detection Operations</td><td>Close, reopen, remediate, and tag detections</td></tr><tr><td>Entity Operations</td><td>Add notes, tags, assignments, and group membership</td></tr><tr><td>Incident Enrichment</td><td>Decorate incidents and synchronize timelines</td></tr><tr><td>Assignment and Triage</td><td>Assign ownership and resolve Vectra assignments</td></tr><tr><td>Notifications</td><td>Send Teams notifications and escalation prompts</td></tr><tr><td>Evidence Collection</td><td>Download PCAP files</td></tr><tr><td>Extensibility</td><td>Provide starter workflows for customization</td></tr></tbody></table>

**Included Playbooks**

<table><thead><tr><th width="335">Playbook</th><th>Purpose</th></tr></thead><tbody><tr><td>VectraGenerateAccessToken</td><td>Generates OAuth access tokens for dependent playbooks</td></tr><tr><td>VectraCloseDetections</td><td>Closes one or more detections with a specified closure reason</td></tr><tr><td>VectraOpenClosedDetections</td><td>Reopens previously closed detections</td></tr><tr><td>VectraSetDetectionStatus</td><td>Acknowledges or closes detections based on Sentinel incident status</td></tr><tr><td>VectraAddNoteToEntity</td><td>Adds notes to Vectra entities</td></tr><tr><td>VectraAddNoteToDetections</td><td>Adds notes to individual Vectra detections</td></tr><tr><td>VectraAddTagToEntity</td><td>Adds tags to Vectra entities</td></tr><tr><td>VectraAddTagToDetections</td><td>Adds tags to individual Vectra detections</td></tr><tr><td>VectraAddTagToSelectedDetections</td><td>Adds tags to analyst-selected detections</td></tr><tr><td>VectraAddTagToEntityAllDetections</td><td>Adds tags to all detections associated with an entity</td></tr><tr><td>VectraAssignDynamicUserToEntity</td><td>Allows analysts to dynamically select and assign a Vectra user</td></tr><tr><td>VectraAssignStaticUserToEntity</td><td>Assigns a predefined Vectra user to an entity</td></tr><tr><td>VectraStaticAssignMemberToGroup</td><td>Adds entities to a predefined group</td></tr><tr><td>VectraDynamicAssignMemberToGroup</td><td>Allows dynamic group selection and entity assignment</td></tr><tr><td>VectraIncidentTimelineUpdate</td><td>Synchronizes and deduplicates Sentinel incident timeline data</td></tr><tr><td>VectraDownloadPcapFileToStorage</td><td>Retrieves PCAP evidence from Vectra to Azure Storage</td></tr></tbody></table>

**Managing Playbooks in the Defender Portal**

Playbooks are configured and managed from the automation section of Microsoft Sentinel.

1. In the Defender portal, go to **Microsoft Sentinel** > **Configuration** > **Automation**.
2. Select the **Playbooks** tab to view and manage all deployed Logic Apps.
3. To attach a playbook to an automation rule, select **Automation rules** and create or edit a rule.
4. In the automation rule, select **Run playbook** as the action and select the desired playbook.

Complete documentation for each playbook is provided in the Vectra RUX Playbooks for Microsoft Sentinel guide. That document includes the deployment, usage, and automation instructions for each playbook.

### Best Practices & Operations

Operational best practices for the Vectra RUX integration are covered in the Vectra RUX Best Practices for Microsoft Sentinel guide. That document includes recommendations for data queries, parser usage, analytics rule configuration, connector operations, and SOC workflow guidance — including how to use automation rules and playbooks across the full incident lifecycle to accurately capture Vectra's MTTI and MTTR metrics.

The same guidance applies when operating this integration from the Microsoft Defender portal. The primary difference is navigation: all Microsoft Sentinel configuration, workbook, and analytics rule pages are accessed under the **Microsoft Sentinel** section of the Defender portal left navigation pane, and the unified incident queue is accessed at **Investigation & response** > **Incidents & alerts** > **Incidents**.

### Appendix: Defender Portal Navigation Reference

The following table summarizes the navigation paths for all key tasks within this integration.

<table><thead><tr><th width="244.84375">Task</th><th>Defender Portal Path</th></tr></thead><tbody><tr><td>Connect Sentinel workspace</td><td><strong>System</strong> > <strong>Settings</strong> > <strong>Microsoft Sentinel</strong> > <strong>Connect a workspace</strong></td></tr><tr><td>Data connectors</td><td><strong>Microsoft Sentinel</strong> > <strong>Configuration</strong> > <strong>Data connectors</strong></td></tr><tr><td>Content Hub</td><td><strong>Microsoft Sentinel</strong> > <strong>Content management</strong> > <strong>Content hub</strong></td></tr><tr><td>Analytics rules</td><td><strong>Microsoft Sentinel</strong> > <strong>Configuration</strong> > <strong>Analytics</strong></td></tr><tr><td>Automation &#x26; playbooks</td><td><strong>Microsoft Sentinel</strong> > <strong>Configuration</strong> > <strong>Automation</strong></td></tr><tr><td>Workbooks</td><td><strong>Microsoft Sentinel</strong> > <strong>Threat management</strong> > <strong>Workbooks</strong></td></tr><tr><td>Advanced hunting (KQL)</td><td><strong>Investigation &#x26; response</strong> > <strong>Hunting</strong> > <strong>Advanced hunting</strong></td></tr><tr><td>Incidents queue</td><td><strong>Investigation &#x26; response</strong> > <strong>Incidents &#x26; alerts</strong> > <strong>Incidents</strong></td></tr><tr><td>Sentinel settings</td><td><strong>System</strong> > <strong>Settings</strong> > <strong>Microsoft Sentinel</strong></td></tr><tr><td>Threat hunting</td><td><strong>Microsoft Sentinel</strong> > <strong>Threat management</strong> > <strong>Hunting</strong></td></tr></tbody></table>

### Appendix: Data Schema

**Detections\_Data\_CCF\_CL**

<table><thead><tr><th width="299">Column</th><th width="145">Type</th><th>Description</th></tr></thead><tbody><tr><td>TimeGenerated</td><td>datetime</td><td>Time the record was ingested or derived from the detection event timestamp</td></tr><tr><td>Type</td><td>string</td><td>Azure Log Analytics table type</td></tr><tr><td>TenantId</td><td>string</td><td>Azure tenant identifier</td></tr><tr><td>_ResourceId</td><td>string</td><td>Azure resource identifier</td></tr><tr><td>id</td><td>real</td><td>Autoincrementing event ID used for checkpointing</td></tr><tr><td>detection_id</td><td>real</td><td>Vectra detection ID</td></tr><tr><td>change_type</td><td>string</td><td>Detection event change type</td></tr><tr><td>event_timestamp</td><td>datetime</td><td>Timestamp of the detection event in Vectra</td></tr><tr><td>event_type</td><td>string</td><td>Vectra event type</td></tr><tr><td>category</td><td>string</td><td>Detection category</td></tr><tr><td>threat</td><td>real</td><td>Threat score</td></tr><tr><td>certainty</td><td>real</td><td>Certainty score</td></tr><tr><td>severity</td><td>real</td><td>Severity score</td></tr><tr><td>d_type_vname</td><td>string</td><td>Human-readable detection type name</td></tr><tr><td>triaged</td><td>bool</td><td>Whether the detection has been triaged</td></tr><tr><td>detail</td><td>dynamic</td><td>Raw detection detail payload</td></tr><tr><td>d_detection_details</td><td>dynamic</td><td>Detection details object</td></tr><tr><td>detection_href</td><td>string</td><td>Direct link to the detection</td></tr><tr><td>detection_type</td><td>string</td><td>Internal detection type identifier</td></tr><tr><td>entity_id</td><td>real</td><td>Associated entity ID</td></tr><tr><td>entity_uid</td><td>string</td><td>Associated entity unique identifier</td></tr><tr><td>entity_name</td><td>string</td><td>Associated entity name</td></tr><tr><td>entity_type</td><td>string</td><td>Associated entity type</td></tr><tr><td>url</td><td>string</td><td>Direct link to associated entity</td></tr><tr><td>mitre</td><td>dynamic</td><td>MITRE ATT&#x26;CK mappings</td></tr><tr><td>is_prioritized</td><td>bool</td><td>Whether the detection is prioritized</td></tr><tr><td>is_targeting_key_asset</td><td>string</td><td>Whether the detection targets a key asset</td></tr><tr><td>unresolved_priority</td><td>bool</td><td>Whether the detection is an unresolved priority</td></tr><tr><td>investigation_status</td><td>string</td><td>Vectra investigation status</td></tr><tr><td>reason</td><td>string</td><td>Reason or status context</td></tr><tr><td>src_host</td><td>dynamic</td><td>Source host object</td></tr><tr><td>src_host_id</td><td>long</td><td>Source host ID</td></tr><tr><td>src_host_ip</td><td>string</td><td>Source host IP address</td></tr><tr><td>src_ip</td><td>string</td><td>Source IP alias</td></tr><tr><td>src_host_name</td><td>string</td><td>Source host name</td></tr><tr><td>src_host_url</td><td>string</td><td>Source host URL</td></tr><tr><td>src_host_certainty</td><td>real</td><td>Source host certainty score</td></tr><tr><td>src_host_threat</td><td>real</td><td>Source host threat score</td></tr><tr><td>src_host_is_key_asset</td><td>bool</td><td>Whether source host is a key asset</td></tr><tr><td>src_host_groups</td><td>dynamic</td><td>Source host group memberships</td></tr><tr><td>src_account</td><td>dynamic</td><td>Source account object</td></tr><tr><td>src_account_id</td><td>long</td><td>Source account ID</td></tr><tr><td>src_account_name</td><td>string</td><td>Source account name</td></tr><tr><td>src_account_url</td><td>string</td><td>Source account URL</td></tr><tr><td>src_account_groups</td><td>dynamic</td><td>Source account group memberships</td></tr><tr><td>dst_host</td><td>dynamic</td><td>Destination host object</td></tr><tr><td>dst_host_id</td><td>long</td><td>Destination host ID</td></tr><tr><td>dst_host_ip</td><td>string</td><td>Destination host IP address</td></tr><tr><td>dst_host_name</td><td>string</td><td>Destination host name</td></tr><tr><td>dst_host_url</td><td>string</td><td>Destination host URL</td></tr><tr><td>dst_host_session_luid</td><td>string</td><td>Destination host session LUID</td></tr><tr><td>dst_host_groups</td><td>dynamic</td><td>Destination host group memberships</td></tr><tr><td>dst_account</td><td>dynamic</td><td>Destination account object</td></tr><tr><td>dst_account_id</td><td>long</td><td>Destination account ID</td></tr><tr><td>dst_account_name</td><td>string</td><td>Destination account name</td></tr><tr><td>dst_account_uid</td><td>string</td><td>Destination account UID</td></tr><tr><td>dst_account_url</td><td>string</td><td>Destination account URL</td></tr><tr><td>dst_account_groups</td><td>dynamic</td><td>Destination account group memberships</td></tr><tr><td>dst_domain</td><td>dynamic</td><td>Destination domain object</td></tr><tr><td>dst_domain_dns</td><td>string</td><td>Destination domain DNS value</td></tr><tr><td>dst_domain_domain</td><td>string</td><td>Destination domain name</td></tr><tr><td>dst_domain_external_target</td><td>string</td><td>Destination external target</td></tr><tr><td>src_external_host</td><td>dynamic</td><td>External source host object</td></tr><tr><td>src_external_host_ip</td><td>string</td><td>External source host IP</td></tr><tr><td>src_external_host_name</td><td>string</td><td>External source host name</td></tr><tr><td>data_source</td><td>dynamic</td><td>Data source object</td></tr><tr><td>data_source_sensor_id</td><td>string</td><td>Sensor ID</td></tr><tr><td>data_source_sensor_name</td><td>string</td><td>Sensor name</td></tr><tr><td>data_source_type</td><td>string</td><td>Data source type</td></tr><tr><td>filters</td><td>dynamic</td><td>Filter metadata</td></tr><tr><td>filters_filtered_by_ai</td><td>bool</td><td>Whether filtered by AI</td></tr><tr><td>filters_filtered_by_rule</td><td>bool</td><td>Whether filtered by rule</td></tr><tr><td>filters_filtered_by_user</td><td>bool</td><td>Whether filtered by user</td></tr><tr><td>filters_is_custom_model</td><td>bool</td><td>Whether custom model filtering applied</td></tr><tr><td>filters_triaged</td><td>bool</td><td>Filter triage state</td></tr><tr><td>assignment</td><td>dynamic</td><td>Assignment object</td></tr><tr><td>assignment_id</td><td>long</td><td>Assignment ID</td></tr><tr><td>assignment_assigned_by</td><td>dynamic</td><td>Assigned-by user object</td></tr><tr><td>assignment_assigned_by_id</td><td>long</td><td>Assigned-by user ID</td></tr><tr><td>assignment_assigned_by_username</td><td>string</td><td>Assigned-by username</td></tr><tr><td>assignment_assigned_to</td><td>dynamic</td><td>Assigned-to user object</td></tr><tr><td>assignment_assigned_to_id</td><td>long</td><td>Assigned-to user ID</td></tr><tr><td>assignment_assigned_to_username</td><td>string</td><td>Assigned-to username</td></tr><tr><td>assignment_date_assigned</td><td>datetime</td><td>Assignment date</td></tr><tr><td>summary</td><td>dynamic</td><td>Detection summary</td></tr><tr><td>grouped_details</td><td>dynamic</td><td>Grouped detection details</td></tr><tr><td>tags</td><td>dynamic</td><td>Detection tags</td></tr><tr><td>normal_domains</td><td>dynamic</td><td>Normal domain context</td></tr><tr><td>external_reference_id</td><td>string</td><td>External ticket or case reference ID</td></tr><tr><td>process_context_data</td><td>dynamic</td><td>EDR or process context data</td></tr></tbody></table>

**Entities\_Data\_CCF\_CL**

<table><thead><tr><th width="299">Column</th><th width="145">Type</th><th>Description</th></tr></thead><tbody><tr><td>TimeGenerated</td><td>datetime</td><td>Time the record was ingested or derived from last modified timestamp</td></tr><tr><td>Type</td><td>string</td><td>Azure Log Analytics table type</td></tr><tr><td>TenantId</td><td>string</td><td>Azure tenant identifier</td></tr><tr><td>_ResourceId</td><td>string</td><td>Azure resource identifier</td></tr><tr><td>id</td><td>real</td><td>Vectra entity ID</td></tr><tr><td>name</td><td>string</td><td>Entity name</td></tr><tr><td>breadth_contrib</td><td>real</td><td>Breadth contribution to urgency</td></tr><tr><td>importance</td><td>real</td><td>Entity importance score</td></tr><tr><td>entity_type</td><td>string</td><td>Entity type</td></tr><tr><td>is_prioritized</td><td>bool</td><td>Whether the entity is prioritized</td></tr><tr><td>severity</td><td>string</td><td>Entity severity</td></tr><tr><td>urgency_score</td><td>real</td><td>Urgency score</td></tr><tr><td>velocity_contrib</td><td>real</td><td>Velocity contribution</td></tr><tr><td>detection_set</td><td>dynamic</td><td>Associated detection set</td></tr><tr><td>last_detection_timestamp</td><td>datetime</td><td>Timestamp of latest detection</td></tr><tr><td>last_modified_timestamp</td><td>datetime</td><td>Last entity modification timestamp</td></tr><tr><td>notes</td><td>dynamic</td><td>Entity notes</td></tr><tr><td>attack_rating</td><td>real</td><td>Attack rating</td></tr><tr><td>privilege_level</td><td>real</td><td>Privilege level</td></tr><tr><td>privilege_category</td><td>string</td><td>Privilege category</td></tr><tr><td>attack_profile</td><td>string</td><td>Attack profile</td></tr><tr><td>sensors</td><td>dynamic</td><td>Associated sensors</td></tr><tr><td>state</td><td>string</td><td>Entity state</td></tr><tr><td>tags</td><td>dynamic</td><td>Entity tags</td></tr><tr><td>url</td><td>string</td><td>Entity URL</td></tr><tr><td>host_type</td><td>dynamic</td><td>Host type details</td></tr><tr><td>account_type</td><td>dynamic</td><td>Account type details</td></tr><tr><td>ip</td><td>string</td><td>IP address</td></tr><tr><td>assignment</td><td>dynamic</td><td>Raw assignment object</td></tr><tr><td>assignment_id</td><td>real</td><td>Assignment ID</td></tr><tr><td>assignment_assigned_by</td><td>dynamic</td><td>Assigned-by user object</td></tr><tr><td>assignment_assigned_by_id</td><td>real</td><td>Assigned-by user ID</td></tr><tr><td>assignment_assigned_by_username</td><td>string</td><td>Assigned-by username</td></tr><tr><td>assignment_date_assigned</td><td>datetime</td><td>Assignment date</td></tr><tr><td>assignment_assigned_to</td><td>dynamic</td><td>Assigned-to user object</td></tr><tr><td>assignment_assigned_to_id</td><td>real</td><td>Assigned-to user ID</td></tr><tr><td>assignment_assigned_to_username</td><td>string</td><td>Assigned-to username</td></tr></tbody></table>

**Lockdown\_Data\_CCF\_CL**

<table><thead><tr><th width="299">Column</th><th width="145">Type</th><th>Description</th></tr></thead><tbody><tr><td>TimeGenerated</td><td>datetime</td><td>Time the record was ingested or derived from lock event timestamp</td></tr><tr><td>Type</td><td>string</td><td>Azure Log Analytics table type</td></tr><tr><td>TenantId</td><td>string</td><td>Azure tenant identifier</td></tr><tr><td>_ResourceId</td><td>string</td><td>Azure resource identifier</td></tr><tr><td>id</td><td>real</td><td>Lockdown record ID</td></tr><tr><td>lock_event_timestamp</td><td>datetime</td><td>Time lockdown was applied</td></tr><tr><td>locked_by</td><td>string</td><td>User who initiated lockdown</td></tr><tr><td>unlock_event_timestamp</td><td>datetime</td><td>Time lockdown expires or was removed</td></tr><tr><td>entity_id</td><td>real</td><td>Locked entity ID</td></tr><tr><td>entity_name</td><td>string</td><td>Locked entity name</td></tr><tr><td>entity_type</td><td>string</td><td>Locked entity type</td></tr><tr><td>certainty</td><td>real</td><td>Certainty score retained for backward compatibility</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.vectra.ai/configuration/response/siem/microsoft-defender-xdr-codeless-connector-framework-rux.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.