# Enrichment Rules

### Overview

Enrichment rules allow you to automatically identify and categorize important entities in your environment, such as privileged roles, critical resources, and non-human identities. After configuring an enrichment rule, matching entities are updated with special attributes. Using these attributes to define filters and conditions enables rules, access reviews, and other capabilities for these special entities.

To create an enrichment rule, you first need to use the [Query Builder](/4yItIzMvkpAvMVFAamTf/features/search/query-builder.md) to save a query identifying the entities to enrich. The criteria can be based on various factors, such as:

* An attribute (e.g., a naming convention or another property that identifies non-human service accounts)
* Permissions granted by a role
* Other distinguishing relationship between entities.

#### Enrichment Rule Types

Veza currently supports five types of enrichment rules:

* **Identify Non-Human Identities**: Automatically label users with the `identity type` attribute by setting the value to `HUMAN` or `NONHUMAN`.
* **Assign Entity Owners**: Assign ownership of entities. Specify a static owner by name or email, or resolve ownership dynamically from a property on the matched entity or a related entity in the graph.
* **Detect Privileged Accounts**: Roles that meet the query condition will have the `is privileged` attribute set to `TRUE`.
* **Classify Critical Resources**: Resources in the query results will have the `criticality level` attribute set to `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`.
* **Assign Veza Tags**: Automatically add or remove [Veza Tags](/4yItIzMvkpAvMVFAamTf/features/search/tags.md) on entities matching the saved query.

When extracting metadata from an integration, Veza will check for matching enrichment rules and update entities that meet the conditions specified by the saved query. For example, an enrichment rule could label roles that grant access to specific permissions or resources as "privileged," mark identities as non-human based on a naming convention, or set a criticality level for resources based on existing tags or attributes.

### Create an Enrichment Rule

Administrators can use the **Integrations** > **Enrichment** page to manage and create rules. To create a rule, you must specify:

* The enrichment rule type.
* The integrations, data sources, and entity type the rule applies to.
* Rule options, such as the criticality level for critical resources.

To define an enrichment rule:

1. **Navigate to the Enrichment Page:**
   * Go to **Integrations** > **Enrichment**.
   * Click **Create Enrichment Rule**.
2. **Select the Integration Type:**
   * Choose an integration from the catalog. Integrations are organized by category (Identity Providers, Cloud Providers, Data Systems, HR Systems, Self Managed Systems, SAAS Apps).
3. **Select the Enrichment Rule Type:**
   * Choose one of the following options:
     * **Identify Non-Human Identities**: For matching users, set the `identity type` attribute value (`HUMAN` or `NONHUMAN`).
     * **Assign Entity Owners**: For matching entities, assign the enriched\_owner attribute to a user from an integrated Identity Provider (IdP) or HRIS, either directly or resolved dynamically from a graph property or saved query.
     * **Detect Privileged Accounts**: For matching roles, set the `is privileged` attribute to `TRUE`.
     * **Classify Critical Resources**: For matching resources, set the `criticality level` attribute (`LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`).
     * **Assign Veza Tags**: For matching entities, add or remove [Veza Tags](/4yItIzMvkpAvMVFAamTf/features/search/tags.md) based on key-value pairs you define.
4. **Name the Rule:**
   * Enter an identifiable name in the **Rule Name** field.
5. **Choose Integrations:**
   * Use the **Integrations** dropdown to select the specific integration instances the rule will apply to.
6. **Select Entity Type:**
   * Choose a supported **Entity Type** (e.g., users, roles, resources) from those data sources.
7. **Pick a Saved Query:**
   * Select a saved query that identifies the entities to enrich.
8. **Set Rule Priority:** Enter a priority value between **0.0** and **10.0**. Defaults to `0.0` if not set. When multiple rules target the same entity, the rule with the higher priority value runs last and takes precedence. Veza recommends setting distinct priorities so rules with overlapping scope resolve predictably.
   * Enter a priority value between **0.0** and **10.0**. When multiple rules target the same entity, the rule with the higher priority value runs last and takes precedence. Rules overwrite rather than merge when they conflict.
9. **Save the Rule:**
   * Click **Save** to apply the changes.

Saving a rule automatically triggers re-extraction for all data sources matching the rule's integrations. You can also trigger extraction manually from **Integrations** > **All Data Sources** > **Start Extraction**.

### Preview Enrichment Rules

When creating or editing an enrichment rule, you can preview the entities that the rule will affect. The preview panel displays each matching entity along with its current enrichment-relevant properties, so you can verify the rule's impact before saving.

To generate a preview, fill in the required fields (rule type, integrations, entity type, and saved query), then click the **Preview** button at the bottom of the form. Key behaviors:

* **Smart column ordering**: The property column relevant to the selected rule type (e.g., `identity_type` for NHI rules, or `Veza Tags` for tag rules) is sorted to the front of the table, so the information you're working with is immediately visible.
* **Clickable entity names**: Click any entity name in the preview to open its node details and inspect all properties.
* **Owner inspection**: For Entity Owner rules, click the owner avatar in the preview to open the owner's node details. This lets you verify owner attributes (such as MFA status or account state) before committing to the rule.
* **Create vs. Edit**: When creating a new rule, the preview is available after completing the required fields. When editing an existing rule, the preview loads immediately using the rule's current configuration.

The preview reflects the current state of the Access Graph at the time of viewing. Re-run extraction after saving the rule to apply the enrichment to all matching entities.

### Entity Owner Enrichment Rules

Entity Owner enrichment rules enable you to assign ownership and accountability for entities across your environment. While commonly used for non-human identities (NHIs) like service accounts and API keys, these rules can apply to any entity type including identities, resources, and roles. Identity provider application entities (`OktaApp`, `OneLoginApp`, `AzureADEnterpriseApplication`, `PingOneApplication`, `PingOneIdentityProvider`, `HashicorpVaultAuthMethodSubresource`, and `CustomIDPApp`) are also supported targets.

{% hint style="warning" %}
**Requires IdP User entities**: The "Assign Entity Owners" option requires Identity Provider (IdP) user entities in your graph. If you see "No IdP User entity types found," integrate an Identity Provider such as [Okta](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta.md), [Azure AD](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure.md), or a [Custom IdP](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/custom-identity-provider-template.md).

After integration, verify users are in the graph by searching for your IdP user type (e.g., `OktaUser`) in Query Builder. Optionally, configure a [Global Identity Provider](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md) to scope owner searches to a specific IdP instance.

When using CMDB-based owner resolution, the resolved `owner_node_id` or `owner_external_id` on the CMDB Configuration Item must still point to an active IdP or HRIS user.

These structural fields are populated by [cross-service connections](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/best-practices/cross-service-connections.md) when the CMDB integration maps owner columns to identity nodes.
{% endhint %}

When you assign an enriched owner, Veza combines it with any existing owners to create a merged **Owners** attribute displayed throughout the platform, which can be used to auto-assign Access Reviews, filter query results, or trigger Rules and Alerts.

To enable an Entity Owner enrichment rule:

1. Create a saved query identifying the entities to enrich
2. Specify the enriched owners from your integrated IdP or HRIS

When enabled, Veza validates the owner exists and sets the `enriched_owner` attribute for matching entities. Veza combines enriched owners with any manually assigned owners to create a merged **Owners** attribute. This merged view appears in:

* Entity detail pages
* Query Builder results (use the `Owners` attribute to filter)
* Access Review auto-assignment
* Rules and Alerts

Use the **Assign Owner with** section to choose how Veza identifies the owner. Select **Name or Email** to enter a fixed owner. Select **Entity Property** to resolve the owner dynamically from a graph property value. The examples below use **Name or Email** assignment.

For example, you can assign an owner to all NHIs in an integration:

* Query condition: `AWS IAM User that are non-human identity type`
* Owner value: Enter the email or username of a user from your IdP (e.g., `cloud-team@example.com`)

Or assign owners by naming convention:

* Query condition: `AWS IAM User that are non-human and name starts with "svc-data-"`
* Owner value: Enter the email or username of a user from your IdP (e.g., `data-team@example.com`)

You can also assign owner by resource access (or based on a relationship to any other destination entity type):

* Query condition: `AWS IAM User that are NHI that have access to S3 bucket "production-data"`
* Owner value: Enter the email or username of a user from your IdP (e.g., `platform-team@example.com`)

#### Dynamic owner assignment

Entity Owner enrichment rules support dynamic owner resolution using graph properties. Select **Entity Property** in the **Assign Owner with** section to configure this. Instead of entering a fixed name or email, Veza resolves the owner from a property value at each extraction cycle.

**Direct property resolution**

When ownership information is stored as a property on the entity being enriched, select the property directly from the **Property** dropdown. Only string properties are available for selection. Veza reads that property's value for each matched entity and uses it to look up the matching IdP user.

Selecting the `id` property resolves the owner using the entity's Veza node ID rather than a named attribute value.

For example, if entities in your environment carry a property identifying the responsible person or team, select that property in the enrichment rule form.

**Related entity resolution**

When ownership information lives on a different entity in the graph, enable the **Use additional query for owner** toggle. Select a saved query as the **Owner Query** that traverses from each matched entity to the related entity holding the owner information. Then select the property from that related entity to resolve the owner.

The Owner Query must be a saved query with exactly one destination entity type.

For example, to assign ownership of service accounts based on a linked Okta user:

1. Create a primary saved query that identifies the service accounts to enrich.
2. Create a saved query from each service account to its linked `OktaUser`, with `OktaUser` as the destination entity type.
3. In the enrichment rule, select **Entity Property**, then enable **Use additional query for owner**.
4. Select this PATH query as the **Owner Query**.
5. Select the `email` property from `OktaUser` as the owner value.

When multiple related entities match a single source, Veza uses the entity with the lowest node ID.

**CMDB-based owner resolution**

The Owner Query can also return CMDB Configuration Items to resolve ownership when your organization tracks application or service ownership in a CMDB such as ServiceNow or Freshservice.

This query does not connect directly from the enriched entity to the owner. Instead, each `CustomCMDBConfigurationItem` carries structural fields, populated during CMDB extraction:

* **`asset_node_id`**: points to the enriched entity (the asset the CI describes).
* **`owner_node_id`**: points to the resolved owner identity in your IdP or HRIS.
* **`owner_external_id`**: the owner's external ID from the source CMDB (used when `owner_node_id` cannot be resolved to a graph node).

These fields are produced upstream during the CMDB integration setup. See [Freshservice CMDB integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/freshservice.md) for the column-mapping configuration that maps CMDB owner columns (e.g., `managed_by`, `assigned_to`) to identity nodes.

For example, to assign ownership of service accounts based on a linked CMDB Configuration Item:

1. Create a primary saved query that identifies the service accounts to enrich (e.g., all NHI accounts in a given integration).
2. Create a saved query with `CustomCMDBConfigurationItem` as the source entity type that returns the relevant CIs.
3. In the enrichment rule, select **Entity Property**, then enable **Use additional query for owner**.
4. Select this CMDB query as the **Owner Query**.
5. Select **`owner_node_id`** (or **`owner_external_id`** as a fallback) as the owner value. See [Get valid other-node queries](/4yItIzMvkpAvMVFAamTf/developers/api/management/enrichment/getvalidenrichmentruleothernodequeries.md) for the underlying API.

The resolved owner must be an active user in your configured IdP or HRIS.

{% hint style="info" %}
**Finding property names:** Use Query Builder to inspect available properties on any entity type. For traversal queries, property names must match the exact key as it appears in the Access Graph. For CMDB queries, only `owner_node_id` and `owner_external_id` are valid.
{% endhint %}

#### Related

* [NHI Suggested Owners](/4yItIzMvkpAvMVFAamTf/features/nhi/nhi-suggested-owners.md): AI-driven owner suggestions for unowned NHIs (a separate feature; complements but does not replace enrichment-rule-based owner assignment).
* [Freshservice integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/freshservice.md): CMDB column mapping that produces the `owner_node_id`/`owner_external_id` fields used by CMDB-based owner resolution.
* [Create enrichment rule](/4yItIzMvkpAvMVFAamTf/developers/api/management/enrichment/createenrichmentrule.md): API reference for the underlying request.

### Assign Veza Tags Enrichment Rules

Veza Tags enrichment rules enable bulk tagging — automatically applying or removing [Veza Tags](/4yItIzMvkpAvMVFAamTf/features/search/tags.md) across large sets of entities based on a saved query. This is the primary way to tag entities at scale within the Veza UI; previously, bulk tagging required the [Tags API](/4yItIzMvkpAvMVFAamTf/developers/api/tags.md).

For each rule you configure two sets of tags:

* **Add Tags**: Tag key-value pairs to apply to all matching entities.
* **Remove Tags**: Tag key-value pairs to remove from all matching entities.

Both fields accept multiple tags. Tags are applied or removed each time a matching data source is extracted. If you disable the rule, the tags it applied are removed from entities on the next extraction.

#### Constraints

| Constraint                            | Limit                                                        |
| ------------------------------------- | ------------------------------------------------------------ |
| Tags per rule (combined add + remove) | 100                                                          |
| Tag key length                        | 255 characters                                               |
| Tag key format                        | Letters, numbers, and underscores (`a-z`, `A-Z`, `0-9`, `_`) |
| Tag value length                      | 4096 characters                                              |

#### Create a Veza Tags Enrichment Rule

1. Go to **Integrations** > **Enrichment** and click **Create Enrichment Rule**.
2. Enter a **Rule Name**.
3. Select **Assign Veza Tags** as the rule type.
4. Use the **Integrations** dropdown to select which integrations the rule applies to.
5. Choose a supported **Entity Type** from those data sources.
6. Select a **Saved Query** that identifies the entities to tag.
7. In the **Add Tags** field, enter one or more key-value pairs to apply to matching entities.
8. In the **Remove Tags** field, enter any key-value pairs to remove from matching entities.
9. Click **Save**.

{% hint style="info" %}
Tags applied by enrichment rules look identical to tags applied manually in the Access Graph. There is currently no UI indicator distinguishing enrichment-managed tags from manually assigned ones. The **Remove Tags** operation only removes tags from entities that are in the current query result set — entities that no longer match the query will not have their tags removed retroactively.
{% endhint %}

### Manage Enrichment Rules

Use the **Integrations** > **Enrichment** page to view all rules and edit or delete individual rules:

1. **Access the Enrichment Page:**
   * Go to **Integrations** > **Enrichment**.
2. **View Rules by Type:**
   * Choose a tab to view rules by type:
     * **NHI**
     * **Entity Owners**
     * **Privileged**
     * **Critical Resources**
     * **Veza Tags**
3. **Edit or Delete Rules:**
   * Click **Edit** to update a rule or **Delete** to remove it.
4. **Enable / Disable Rules:**
   * Toggle the switch in the **Enabled** column to activate or deactivate a rule.
   * Toggling a rule does not trigger re-extraction. The change takes effect at the next scheduled extraction or when you manually trigger extraction from the **All Data Sources** page.
   * Disabling a rule removes its enrichment metadata from existing entities upon the next data source extraction.


---

# Agent Instructions: 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:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/configuration/enrichment.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.