> 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/integrations/configuration/enrichment.md). # 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`. 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. Veza recommends setting distinct priorities so rules with overlapping scope resolve predictably. 9. **Preview the Results** * Click **Preview** to perform a dry-run and visualize what the rule would change. 10. **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: * **Clickable entity names**: Click any entity name in the preview to open its node details and inspect its **current** 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. 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, 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 %} 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 that the owner exists and is active, then sets the `enriched_owners` attribute for matching entities. Veza combines enriched owners with any manually assigned owners to create a `merged_owners` attribute. This attribute appears as **Entity Owners** in: * Entity detail pages * Query Builder results (use the `Owners` attribute to filter) * Access Review auto-assignment * Rules and Alerts In the rule builder, the **Assign Owner** box in the **Entity Owners** sidebar section offers three ways to assign owners: 1. **Set a specific person as the owner** 2. **Match by a property of this entity type** 3. **Match by a property of a Related Entity** {% hint style="info" %} If you have [configured a Global IdP](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md), owners are required and validated to be a part of the configured IdP. {% endhint %} #### Set a specific person as the owner In this mode, you choose static selections from a list of active IdP Users. #### Match by a property In this mode, the owner is dynamically resolved from a graph property value. Only string properties are available for selection. This is useful when ownership information is already available and can be derived. In the rule form, this option appears as **Match by a property of this *****{entity type}***, where *{entity type}* is the entity type you selected. For example, consider this configuration: * **Query**: All Okta Users * **Global IdP**: Okta * **Property**: `manager` * **Matching IdP property**: `email` For each matched entity, Veza reads the value of its `manager` property and assigns the owner by finding the `OktaUser` whose `email` matches that value. #### Match by a property of a Related Entity In this mode, ownership information lives on a different entity in the graph. You select a saved 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 'Related Entity 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 **Match by a property of a Related Entity**. 4. Select this PATH query as the **Related Entity Query**. 5. Select the `email` property from `OktaUser` as the owner value. This signals which property to extract the **value** from. 6. Select the `email` property for your selected **IdP Type**. This signals which **attribute** to filter for in combination with the **value** from the previous step. When multiple related entities match a single source, Veza uses the entity with the lowest node ID. **CMDB-based owner resolution** The Related Entity Query can also return CMDB Configuration Items, resolving ownership from records your organization maintains in a CMDB such as ServiceNow or Freshservice. This is the end-to-end path for assigning owners to NHIs and resources from CMDB data. See [Assign Entity Owners from CMDB Data](/4yItIzMvkpAvMVFAamTf/integrations/configuration/cmdb-owner-assignment.md) for the structural fields, prerequisites, and full procedure. {% 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 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/integrations/configuration/enrichment.md?ask=&goal= ``` `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.