> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/search/saved-queries.md).

# Saved Queries

Use the **Access Visibility** > *Queries* page to review and manage all queries within Veza. This includes both pre-built assessments and user-created queries composed using the [Query Builder](/4yItIzMvkpAvMVFAamTf/features/search/query-builder.md).

Veza ships with hundreds of pre-built security queries, organized by integration, category, and use case. Many of these out-of-the-box queries are featured in Veza's dashboards. You can customize dashboards by cloning existing queries, editing them, or creating new queries.

This flexibility enables tailoring Veza insights to your specific security needs and environment. You can use saved queries to:

* **Set risk levels for entities**: Define [Risks](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md), marking entities in the query results with a risk score.
* **Define access review scopes**: Choose a saved query when creating a [Review Configuration](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/review-configuration.md#step-2-define-the-review-scope) to review the current query results, once or according to a schedule. Queries used in scheduled reviews must be **public**, because the scheduler runs in a system context that cannot access private queries.
* **Trigger Alerts, Email Notifications, and Veza Actions**: Saved queries can trigger [Alert Rules](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) when the results or their attribute values meet certain conditions.
* **Create shared dashboards for Veza users and teams**: Create custom [Dashboards](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards.md) to organize and share queries.
* **Identify NHI, critical resources, and privileged roles**: Define [Enrichment Rules](/4yItIzMvkpAvMVFAamTf/integrations/configuration/enrichment.md) to mark saved query results as privileged roles, human or non-human identities, or set the criticality level of resources that meet the query conditions.
* **Export Results**: Download or schedule result exports in CSV format, by email or to an integrated [Snowflake database](https://github.com/cookieai-jar/cookie-docs/tree/main/docs/integrations/snowflake/saved-query-export-to-snowflake.png).

## Query visibility

Query visibility in Veza is controlled by two factors: the query's **visibility setting** (Public or Private) and your **team's integration scope**.

### Query visibility settings

Each saved query has a visibility setting that determines who can access it:

| Visibility            | Who can access                                                                                                          |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Private** (default) | The query creator and users explicitly added as query owners                                                            |
| **Public**            | Any authenticated Veza user in your tenant with a role that includes query access (Admin, Operator, Viewer, or similar) |

{% hint style="info" %}
**Adding query owners** is currently only available via the API. Use the [Update query owners](/4yItIzMvkpAvMVFAamTf/developers/api/query-builder/updateassessmentquerypermissions.md) endpoint to specify which users can access a private query by user ID.
{% endhint %}

{% hint style="warning" %}
**Visibility is a one-way setting.** Once a query is set to **Public**, it cannot be reverted to Private. Carefully consider this before making a query public.
{% endhint %}

{% hint style="info" %}
**Changing query visibility** requires the Operator role or higher, and you must be logged in as a member of the **root team**. Users in non-root teams, or with only the Viewer role, cannot change a query's visibility setting.
{% endhint %}

### Sharing queries across teams

Custom queries are **Private by default** and are not visible to users in other teams. To make a query accessible to users in non-root teams, set its visibility to **Public** via **Edit Configuration** → **Visibility**.

{% hint style="info" %}
Even after setting a query to Public, each team sees results scoped to their integration access. Users in a non-root team can see the query but will only see data from integrations within their team's scope.
{% endhint %}

To share multiple queries with another team, the recommended approach is to add them to a [shared dashboard](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards/dashboard-sharing.md).

### Visibility by team and role

Beyond the visibility setting, your role and team membership determine what queries you see:

| Context                                                            | Query access                                | Result scope                           |
| ------------------------------------------------------------------ | ------------------------------------------- | -------------------------------------- |
| **Root team — Operator, Access Reviews Admin, NHI Security Admin** | Public queries + queries you created or own | All integrations                       |
| **Root team — Viewer**                                             | Public queries + queries you created or own | All integrations                       |
| **Non-root team — any role**                                       | Public queries + queries you created or own | Only integrations in your team's scope |

{% hint style="info" %}
Pre-built Veza queries are Public and visible to all users. Users in non-root teams see the pre-built queries filtered to the integrations their team has access to.
{% endhint %}

## Sharing queries

Veza provides four ways to share queries or query results with other users and teams:

### 1. Share via URL (copy link)

From the **Query Details** page, click the share icon to copy the query URL to your clipboard. Send this link to other Veza users to give them direct access to the Query Details page.

**Who can use the link:**

* The recipient must be an **authenticated Veza user in the same tenant**
* For **Public** queries: any authenticated user with a role that includes query access (Admin, Operator, Viewer, or similar)
* For **Private** queries: only the query creator and users added as query owners

{% hint style="info" %}
The shared link requires authentication. Recipients who are not signed in are redirected to the Veza login page. The link does not bypass access controls.
{% endhint %}

### 2. Share via dashboard

Add the query to a custom dashboard, then share the dashboard with other teams or via email. This is the recommended approach for making queries accessible across teams.

* **Share with teams**: Requires Operator role or higher. The shared dashboard appears in the recipient team's **Shared** section.
* **Share via email**: Available to any role. Sends a notification email with a link to view the dashboard.

See [Dashboard Sharing](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards/dashboard-sharing.md) for full details.

{% hint style="info" %}
When a dashboard is shared with a team, users in that team can view all queries on the dashboard, scoped to their integration access. No separate query-level permission changes are needed.
{% endhint %}

### 3. Share results via Remediate

From the **Query Details** page, click **Remediate** to send query results directly to a Slack channel or email recipients.

{% tabs %}
{% tab title="Share via Slack" %}

1. Click **Remediate** and select **Share via Slack**.
2. Select one or more configured Slack Veza Actions.
3. Optionally add a note.
4. Click **Send**. The query results are posted to the selected Slack channel(s).

Requires at least one configured Slack Veza Action under **Settings** > **Notifications**. See [Remediate via Slack](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-slack.md).
{% endtab %}

{% tab title="Share via Email" %}

1. Select specific rows in the query results table.
2. Click the share icon and select **Share via Email**.
3. Select email recipients, add an optional subject and note.
4. Click **Send**.
   {% endtab %}
   {% endtabs %}

{% hint style="warning" %}
Sharing via Remediate requires the **Query Remediation** feature to be enabled for your tenant, and the Remediate permission held by Admin, Operator, Access Reviews Admin, and NHI Security Admin roles.
{% endhint %}

### 4. Export results

Download or schedule delivery of query results as a file:

| Export method                      | Format                    | Description                                                                                 |
| ---------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------- |
| **Save Results as CSV**            | CSV (immediate download)  | Downloads the full result set immediately. Disabled when results reach 10,000 rows or more. |
| **Send email with Results as CSV** | CSV attachment via email  | Delivers results to your email address as a CSV attachment.                                 |
| **Export to Snowflake**            | Sent to Snowflake         | Sends results to a connected Snowflake database.                                            |
| **Schedule Export**                | CSV via secure email link | Delivers results on a recurring schedule; links expire after 28 days.                       |

{% hint style="info" %}
**Save Results as CSV**, **Send email with Results as CSV**, and **Schedule Export** are available from both the saved query details page and Query Builder. **Export to Snowflake**, **Copy Query Spec API**, and **View Query Spec API** are only available in Query Builder.
{% endhint %}

See [Scheduled Exports of Query Results](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards/query-export-to-email.md) for details on scheduled delivery.

### Actions column and filter

The Queries table includes an **Actions** column indicating whether each query has at least one [rule](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) with an action attached, such as a **Send Alert** notification or a **Create Review** certification (see [Assign Rules to Saved Queries](#assign-rules-to-saved-queries)). A green **Yes** marks queries with one or more actions; a red **No** marks those with none.

Use the **Actions** filter above the table to show only queries that have actions or only those that do not. This helps you find queries that detect security conditions but have no action configured.

{% hint style="info" %}
The **Actions** column is distinct from the **Actions** button (⋮) on each row. The column reports whether actions are *configured* for a query; the button is where you *take* actions on a query, such as managing rules or setting a risk level.
{% endhint %}

### Managing saved queries

On the Saved Queries page, use the **Actions** button to the right of each query to choose from available actions, which include:

* **Manage Rules**: Define and edit [Alert Rules](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) for the query.
* **View Alerts**: Review alert details for the query.
* **Schedule Export**: Configure [Schedule Export](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards/query-export-to-email.md) for the query.
* **Set Risk Level**: Define a [Risk Level](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md) for the query.
* **Disable Query** / **Enable Query**: Exclude the query from evaluation, or resume evaluation. See [Disable and enable queries](#disable-and-enable-queries).
* **Clone**: Create a copy of the query.
* **Delete**: Remove the query.
* **Open in Query Builder**: Edit the query.

#### Editing saved queries

Editing saved queries allows you to refine and customize your security assessments as your environment evolves, and ensure that your security insights remain relevant and accurate over time. You might edit a query to:

* Adjust filters to include or exclude specific entities
* Modify the query scope as new integrations are added
* Update risk levels or alert conditions
* Fine-tune the query for better performance or more targeted results

To edit a saved query:

1. Open the **Access Visibility** > **Queries** page and find a query you want to edit or act on.
2. Click on the query name to edit it in [Query Builder](/4yItIzMvkpAvMVFAamTf/features/search/query-builder.md).
3. Make any changes and click *Save* to finish saving the query.

Use the Query Builder *Save* menu to perform specific actions for the query:

![Saved query options](/files/7w3fuciJhEZdE8rg1zfO)

* **Quick Save**: Quickly save any new filters without changing other settings.
* **Save as New**: Copy this query to modify it while preserving the original.
* **View Details**: Show configuration details and metadata for this saved query.
* **Edit Configuration**: Modify the basic settings of this query, including name, description, and **visibility** (Private or Public). Setting a query to Public makes it visible to all authenticated users in your tenant. Note that Public queries **cannot be changed back to Private**.
* **Edit Rules**: Configure or modify alert rules associated with this query.
* **Edit Dashboards**: Add this query to dashboards or remove it from dashboards it's currently part of.
* **Save Results as CSV**: Download the current query results as a CSV file. Disabled when results reach 10,000 rows or more.
* **Send email with Results as CSV**: Deliver results to your email address as a CSV attachment.
* **Export to Snowflake**: Send the query results to a connected Snowflake database.
* **Schedule Export**: Set up an automated, recurring export of this query's results.
* **Copy Query Spec API**: Copy the API specification for this query for use with the Veza Query Builder API.
* **View Query Spec API**: Display the API specification for this query for reference or debugging.

#### Bulk-edit labels on multiple queries

Apply or remove labels across many saved queries in a single action. Use this to group queries by initiative (`sox_2026`, `q2_risk_burndown`), domain (`nhi`, `saas_apps`, `privileged_access`), or any classification scheme your team uses to organize a large query catalog.

{% hint style="info" %}
Labels also drive **Dynamic** dashboards: applying a label to a query surfaces it in any Dynamic dashboard built from that label. See [Creating a Dashboard](/4yItIzMvkpAvMVFAamTf/features/insights/dashboards.md#creating-a-dashboard).
{% endhint %}

{% hint style="info" %}
**Permission required.** Bulk-editing labels requires a role with permission to update assessment queries: **Admin**, **Operator**, **Access Reviews Admin**, or **NHI Security Admin**. Users without this permission do not see the **Edit Labels** button, even when rows are selected.
{% endhint %}

To bulk-edit labels:

1. Open the **Access Visibility** > **Queries** page.
2. Select queries using the row checkboxes:
   * Click the checkbox on individual rows to select specific queries.
   * Click the header checkbox to select every query on the current page (up to the page size, typically 30 rows). Selections persist as you paginate through the filtered result set.
3. With one or more queries selected, the toolbar replaces **Export** and **Columns** with an **Edit Labels** button, and the table title shows the selection count (`N selected`) above the total query count.
4. Click **Edit Labels** to open the modal.
5. Use the labels picker to add or remove labels:
   * The picker pre-fills with labels currently applied to **every** selected query. Labels applied to only some of the selected queries are not pre-filled.
   * **To add a label**, select it from the dropdown. The label is added to every selected query that does not already have it.
   * **To remove a label**, click the `×` on a pre-filled label chip. The label is removed from every selected query that has it.
6. The footer summarizes pending changes (for example, *"2 labels added to as many as 30 selected queries"*).
7. Click **Save** to apply the changes. A success notification confirms the result; on partial failure, the notification reports the number of queries that could not be updated.

#### Creating new labels inline

You can create new labels directly from the **Edit Labels** modal. Type the label text in the picker — Veza normalizes the input to match the required label format and shows a **Create New Label** option in the dropdown:

* Lowercase letters, digits, and underscores only (`a–z`, `0–9`, `_`).
* Spaces and hyphens are converted to underscores.
* Other characters are stripped.
* Leading, trailing, and repeated underscores are collapsed.

For example, typing `Docs Test Label` displays the create option as `Docs Test Label → docs_test_label`. Click the option to add the normalized label to the selection. The new label is created when you click **Save** and becomes available for future use across all queries in your tenant.

{% hint style="warning" %}
**Limits and constraints**:

* A single bulk-edit action accepts a maximum of **100 queries**. To label more than 100 queries, repeat the action in batches.
* Each query is processed independently. If the action fails on individual queries (for example, due to scope restrictions), the remaining queries are still updated and the failures are reported.
* A label cannot appear in both the add and remove sets in the same action.
* All bulk label changes are recorded in the [audit log](/4yItIzMvkpAvMVFAamTf/administration/administration/events.md) as **Bulk Update Assessment Query Labels** events on the affected queries.
  {% endhint %}

#### Disable and enable queries

Disable a query to exclude it from evaluation without deleting it. A disabled query keeps its definition, labels, risk level, and historical results, but Veza stops acting on it. While a query is disabled, it:

* Is not run on the assessment schedule.
* Does not contribute to [risk scores](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md) and does not appear on the Risks page.
* Does not trigger [rules or alerts](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md).
* Does not appear as a tile on dashboards.

Re-enable a query to resume evaluation. The query is picked up again on the next scheduled assessment run, with its prior history intact.

The Queries page includes a **Status** column that shows an **Active** or **Disabled** badge for each query, and a **Status** filter (**Enabled** / **Disabled**) so you can list only active or only disabled queries.

{% hint style="info" %}
**Permission required.** Disabling and enabling queries requires the **Admin** or **Operator** role.
{% endhint %}

**Queries with dependencies.** If a query is referenced by other features — an alert rule, an enrichment rule, or a scheduled export — Veza prompts you to confirm before disabling it, warning that dependent rules, alert actions, and reviews will be paused. Click **Continue** to disable the query, or cancel to keep it active. Queries with no dependencies are disabled without a prompt.

To disable or enable a single query:

1. Open the **Access Visibility** > **Queries** page.
2. Click the **Actions** menu (⋮) for the query.
3. Select **Disable Query**, or **Enable Query** for an already-disabled query.
4. If the query has dependencies, click **Continue** in the confirmation prompt.

The action is recorded in the query's change history — open **View Change History** from the query's **Actions** menu.

**Disable or enable queries in bulk**

Select multiple queries with the row checkboxes, then disable or enable them together from the toolbar.

1. Open the **Access Visibility** > **Queries** page.
2. Select queries using the row checkboxes. Selection and pagination behave the same as for [bulk label editing](#bulk-edit-labels-on-multiple-queries).
3. With one or more queries selected, the toolbar shows the selection count (**N selected**) alongside **Enable**, **Disable**, and **Edit Labels** buttons.
4. Click **Disable** or **Enable** to apply the change to the selected queries.

{% hint style="info" %}
**Limits.** A single bulk disable or enable action accepts a maximum of **100 queries**. To act on more, repeat in batches. Each query is processed independently: if some fail (for example, due to scope restrictions), the rest still succeed and the failures are reported.
{% endhint %}

### Viewing saved query results

Veza offers different ways to view and analyze saved query results, each suited to different use cases.

We recommend starting with the Query Details view for a quick, accessible overview of your results. From there, you can dive deeper into other views as needed for more detailed analysis.

You can access each view using the **Actions** menu on the **Saved Queries** page:

* **Query Details**: A simplified view of your query results, ideal for:
  * Quick overviews of key findings
  * Reviewing trends and changes over time
  * Accessing associated risks, rules, and reports
* **Query Builder**: A comprehensive, tabular view of results and query editor. Use this when you need to:
  * Perform detailed analysis of all entity attributes
  * Apply additional filters or modify the query
  * Export granular data for further processing
* **Graph**: A visual representation of entities and their relationships. This view is best for:
  * Understanding complex access paths
  * Identifying indirect or unexpected connections
  * Exporting a clear picture of your security posture for stakeholders
* **Trend Chart**: Shows changes in query results over time. Use this to:
  * Track the effectiveness of security measures
  * Identify patterns or anomalies in access behaviors
  * Generate visual reports for compliance and auditing purposes

### Assign Risk Levels to Saved Queries

Assigning risk levels to saved queries can help prioritize security efforts and enhance visibility into your organization's risk landscape. By doing so, you:

* Highlight critical security issues that require immediate attention
* Provide context for decision-making during access reviews
* Enable risk-based reporting and tracking of security improvements over time
* Facilitate communication about security priorities across teams and to leadership
* Automate risk-based alerting and response workflows

This risk-based approach allows you to focus resources on the most significant threats to your organization's security posture, making your security operations more efficient and effective.

To enable [risks](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md) for a query:

1. Find the query on the **Access Visibility** > **Saved Queries** page.
2. Expand the **Actions** dropdown menu and click **Set Risk Level**.
3. Use the dropdown menu to set the risk level to `None`, `Low`, `Medium`, `High`, or `Critical`.
4. Click *Save*.

After defining a risk using a saved query, entities in the results will be assigned a "Low", "Medium", "High", or "Critical" risk score. The [Risk Score](/4yItIzMvkpAvMVFAamTf/features/insights/risks.md) varies depending on how many queries with risks an entity is in the results of.

Defining custom risks using saved queries can help reviewers make decisions during access reviews, track risk burndown, and provide visibility into your most critical identities, access controls, services, and resources.

{% hint style="info" %}
**Risk Exclusion**: You have several options to manage how entities appear in risk calculations:

* **Mark as Exception**: Search for an entity on the **Access Intelligence** > **Risks** page, and click *Actions* > *Mark as Exception* to exclude it from a specific risk query.
* **Bulk Omit**: Exclude multiple risk queries from an entity's risk score calculation at once. In **Query Details** > **Results** view, click on a risk score to view details, then click **Bulk Omit**, select the queries to exclude, and click **Omit Selection**. This is useful for eliminating false positives and refining risk accuracy.
* **Query Filters**: Add filters to the original query to automatically exclude entities matching certain criteria from the results.

Risk scores automatically recalculate within a few hours after making exclusions.
{% endhint %}

### Assign Rules to Saved Queries

Adding rules to saved queries enables automated monitoring and response to changes in your security posture. By creating rules, you can:

* Get notifications when critical access patterns change
* Automate the creation of access reviews for specific conditions
* Trigger remediation workflows when potential risks are detected
* Maintain continuous compliance with internal policies and external regulations

Rules transform static queries into dynamic security controls, helping you proactively manage access risks.

To assign rules to a saved query:

1. Choose *Manage Rules* from the actions dropdown menu.
2. Use the [Rule Builder](/4yItIzMvkpAvMVFAamTf/features/insights/rules-and-alerts.md) to define the alert details, conditions, and actions. See [Veza Actions](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md) for more information about configuring emails, integrations, and webhooks as targets.
   1. Click **Add New Rule**.
   2. **Details**: Give the rule a name, description, and severity level for categorizing the rule.
   3. **Conditions**: Trigger the alert based on changes in the query results, or when results have specific properties (often referred to as attributes).
   4. **Action | Send Alert**: Create alerts shown on the **Rules and Alerts** page (accessible from the **Alerts** bell icon in the top toolbar), and optionally deliver them using Veza Actions.
   5. **Action | Create Review**: Start a new [Review](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/create-access-review.md) from an existing review [Configuration](/4yItIzMvkpAvMVFAamTf/features/access-reviews/how-to/review-configuration.md).


---

# 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.veza.com/4yItIzMvkpAvMVFAamTf/features/search/saved-queries.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.
