> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-datasets.md).

# Manage access to datasets

Manage Cortex XDR user-managed dataset access with role permissions, object sharing, owners, editors, and viewers.

Review the following:

* [Manage access to objects](/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects.md)

The **Dataset Management** page serves as the central repository for your user-defined data. By using object-level access, you can ensure that specific datasets, such as sensitive Lookups or Correlation results, are only accessible to authorized users and user groups. By default, newly created datasets are **Restricted**.

{% hint style="warning" %}
**Prerequisite**

**Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**.\
The configuration of these settings defines the authorized sharing workflows for datasets in the **Dataset Management** page, including the options that appear to users when right-clicking a dataset in the table:

* **Owners can Share objects they created** (default): Grants owners the ability to share datasets with specific users and user groups to the dataset's access list. In the **Dataset Management** page, this enables the **Share** option.
* **Owners and editors can change the general access** (default): Allows owners and any user with Editor access to manage **General access** (**Public** vs. **Restricted**). In the **Dataset Management** page, this replaces the **Share** option with the **Manage Access** option.
* **Default access for newly created objects**: New datasets follow the access level defined in your tenant settings, which defaults to **Restricted**.

For more information on these tenant-level configurations, see [Manage access to objects](/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects.md).

* Define Scope-Based Access Control (SBAC): While object-level sharing grants access to the dataset's configuration and ability to be queried, users must also have the appropriate SBAC permissions to view the actual data rows within the dataset. For more information on defining SBAC, see [Manage user scope](/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-user-scope.md).
  {% endhint %}

### Implicit sharing and dependencies

Sharing is not inherited across dependent objects; each layer must be shared explicitly to ensure successful execution.

* **Dataset views**: Sharing a Dataset View does not automatically share the underlying User, Lookup, or Raw datasets it queries. A user with **Viewer** access to a Dataset View can run the view and see its results, but a direct query against an underlying dataset will fail unless that specific dataset is also shared with them.
* **Correlation rules**: If you create a correlation rule that uses **Save to dataset** to write to a dataset, you must be the **Owner** or **Editor** of that target dataset. If your Editor access is later revoked, the rule continues to evaluate, but the write action will fail.
* **Query Library**: Sharing a saved query does not grant access to the datasets it references. A user can view and edit the saved query text, but running it will fail at runtime with a "dataset not found" or "access denied" error if the user lacks explicit access to the underlying dataset.

### Correlation rules and scheduled queries

Background executions, such as active correlation rules (using **Save to dataset**) and scheduled queries, run with system-level privileges and therefore bypass object-level dataset permissions at runtime. This means a scheduled query or correlation rule can write to or query a **Restricted** dataset even if the configuring user lacks explicit **Editor** or **Viewer** access. Per-object enforcement applies strictly to real-time, ad-hoc query executions.

To reduce the risk of bypassing dataset permissions, Cortex XDR performs a validation check when a scheduled query or correlation rule is created or modified. If the creator does not have **Editor**/**Owner** rights to the target dataset (or the **Create Datasets** permission when the dataset does not yet exist), they are blocked from saving the rule or query. Administrators should treat the creation of scheduled queries and correlation rules as highly privileged actions.

### Supported dataset types

Per-object access applies strictly to user-managed datasets:

* **Lookup datasets**: Key-value pairs created through upload (CSV/JSON) to Cortex XDR, Cortex Query Language (XQL) `target`, API, or data sources/connectors.
* **User datasets**: Custom datasets generated via XQL `target` command or Notebooks SDK.
* **Dataset views**: Virtual representations of data built via XQL queries in Cortex XDR.
* **Correlation datasets**: Generated via Correlation Rules (**Save to dataset**).

{% hint style="info" %}

#### Note

System-managed datasets, Raw, System, Snapshot, and External (Federated Search), continue to be managed through existing role-to-dataset mappings in **Settings** → **Configurations** → **Access Management** → **Roles** under **Datasets**.
{% endhint %}

### How access impacts XQL Search

The permissions assigned to your role, combined with the ownership of specific datasets, directly change the tools available to you while working in XQL Search:

* **Visibility and autocomplete**: Your XQL Search view is personalized. You will only see and receive autocomplete suggestions for datasets where you are the **Owner**, or those shared with you as a **Viewer** or **Editor**, or marked as **Public**.
* **Writing data**: Running a query with target type = dataset or target type = lookup against an existing dataset requires **Editor** or **Owner** access. This prevents users with only **Viewer** access from unintentionally modifying or appending data to datasets maintained by other teams. If you only have **Viewer** access, the query will fail with a permission error.
* **Dynamic creation**: If a target dataset does not exist when a query is executed, the system creates it only if your role has the **Create Datasets** permission. The system dynamically creates the dataset, assigns you as the **Owner**, and applies the initial access state defined in your tenant-level settings (**Restricted** by default).

### How to configure access to datasets

Setting up access involves enabling role capabilities and then defining the audience for individual dataset objects.

**Step 1: Define role capabilities** 

Role-level permissions act as the "master switch" and determine what actions a user can take in the Dataset Management page.

1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role and select **Edit Role**.
3. Under **Components**, expand **Data Management**.
4. Set **Dataset Management** to **Enabled**.
5. Assign specific capabilities:
   * **Create Datasets**: Enables the user to create new supported dataset types. The user who performs this action becomes the **Owner** and the dataset is assigned an initial access state based on your tenant-level settings.
   * **Edit Public Datasets**: Allows the user to modify (append or overwrite) custom datasets set to **Public**, even if they are not the owner.

**Step 2: Manage sharing for a specific dataset** 

Once a dataset exists in the **Dataset Management** page, the **Owner** (or an authorized Editor) defines who can see or edit it.

1. Select **Settings** → **Configurations** → **Data Management** → **Dataset Management**.
2. Locate the dataset in the **Datasets** or **Dataset Views** table.
3. Right-click the dataset and select **Share**.
4. (If sharing is enabled) Search for the **User** or **User Group**.
5. Assign the access level: **Viewer** (read/query) or **Editor** (modify/append).
6. Set the **General access** state:
   * **Restricted**: Private to the Owner and explicitly added principals.
   * **Public**: Visible to all users with the **Dataset Management** component enabled.
7. Click **Save**.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-datasets.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.