# Managing Identities
### **Identities**
Identities in Veza Lifecycle Management represent a top-level view of an individual user, used to automate provisioning and deprovisioning across systems, applications, or services.
This can include birthright access managed throughout the user's lifecycle, triggered by joiner, mover, or leaver events, as well as ad-hoc, just-in-time access granted upon approval of an access request.
Identities can refer to users who may be employees, contractors, or external collaborators (partners). Additionally, Veza supports lifecycle management for Non-Human Identities (NHI), such as service accounts, though with a simplified action set. See [NHI Security > Lifecycle Management for NHI](/4yItIzMvkpAvMVFAamTf/features/nhi.md#lifecycle-management-for-nhi) for details on NHI-specific capabilities and limitations.
With Lifecycle Management, workflows defined within policies dictate the users’ onboarding, job-function change, and offboarding processes, ensuring that corresponding identities have precisely the access they need as their roles evolve or their status within the organization changes. Similarly, access granted to identities may also change as just-in-time access requests are fulfilled or revoked.
The **Lifecycle Management** > **Identities** page serves as a central hub for viewing identities known to Lifecycle Management and Access Requests, as well as performing actions on individual identities.
Identities are populated into Lifecycle Management by first identifying the entire user population by **integrating** their source of identity (SOI) and creating and enabling a policy that uses that data source. A policy does not require configured workflows to begin populating identity data. Enabling a policy against an identity source is sufficient to start the Identities table. This may require enabling a built-in integration for your identity source (e.g., Workday integration), uploading user data in CSV format (CSV Upload integration), or using a custom OAA connector.
See [Integrations](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/integrations.md) for detailed information on integrating the source of identity.
For Integration management using APIs, see [the Datasource Management APIs](/4yItIzMvkpAvMVFAamTf/developers/api/management/datasources.md).
#### **Identity Synchronization**
Identities are maintained through **synchronization** with the identity sources. Syncing identities ensures that all systems reflect the most current user state, whether through onboarding, role changes, or attribute updates, keeping access aligned, consistent, and audit-ready.
The **Sync Identities** action is used for the automatic synchronization of user identities between an authoritative source (such as an HR system or identity provider) and target systems. In the Lifecycle Management workflow, Sync Identities works alongside other key actions:
* Manage Relationships (handling group/role memberships)
* Deprovision Identity (removing access when users leave the organization)
Synchronization is executed through Lifecycle Management policy workflows. Policy workflows can be defined with triggers and actions to synchronize changes in your identity source with target systems. Additionally, SCIM (System for Cross-domain Identity Management) or **OAA** (Open Authorization API) can enable identity sync for a wide range of target applications that don't have a built-in Veza integration, but do expose standard user and group management APIs or support bulk data export.
* See [SCIM](/4yItIzMvkpAvMVFAamTf/integrations/integrations/scim/provisioning.md) for more information on usage.
* See [Open Authorization API (OAA)](/4yItIzMvkpAvMVFAamTf/developers/api/oaa.md) for detailed information.
#### **Multi-Value Attribute Management**
Active Directory supports appending values to multi-value attributes during Identity Sync actions. This allows you to add new values without replacing existing ones.
For detailed information about appending multi-value attributes, including supported attributes, syntax, and examples, see [Appending Multi-Value Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md#appending-multi-value-attribute-active-directory-only) in the Transformers documentation.
#### **Identities Table**
| Column | Description | Usage |
| ---------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |
| **Name** | Identity display name | The full display name is an attribute composed of the user's first name and last name. |
| **Status** | Current lifecycle status (Active/Inactive) | Indicates employment status. |
| **Property Overrides** | Shows "Yes" if identity has custom attribute overrides | Identifies identities with manual attribute modifications (overriding attributes from your SOI ) |
| **Department** | Organizational department from SOI | Used for access assignment and reporting |
| **Policy** | Associated Lifecycle Management policy | Links identity to a specific Lifecycle Management workflow |
| **Access Profiles** | Assigned Access Profiles with counts | Shows current access assignments |
| **Last Changed at** | Timestamp of the most recent update | Tracks synchronization and change activity |
| **Workflows** | Associated Lifecycle Management workflow name | Identifies which policy workflow manages the identity |
> **Note:** The display name is not the primary unique identifier, as multiple users may share the same first and surname.
#### **Identity attribute display priority**
When an identity has multiple sources (primary and secondary), the Identities table displays attributes based on the active status of each source. The "active" status is determined by the `is_active` field in each source of identity, which typically represents employment or account status (e.g., an active employee in Workday, an active contractor account in a secondary system).
**Display Priority:**
| Primary Source Status | Secondary Source Status | Displayed Attributes Source |
| --------------------- | ----------------------- | --------------------------- |
| Active | Any | Primary source |
| Inactive | Active | Secondary source |
| Active | Active | Primary source (default) |
| Inactive | Inactive | Primary source (default) |
This behavior ensures the table reflects the most current and relevant source of identity information. For example, when an employee terminates (primary source becomes inactive) but remains as an active contractor in a secondary source, their attributes are displayed from the contractor system.
{% hint style="info" %}
**Early Access:** Enhanced display prioritization may require Veza support to enable. Contact your Customer Success Manager for scenarios where secondary identities should be displayed when primary identities become inactive.
{% endhint %}
#### **Filter and Search an Identity**
To start, you can use filtering options to locate specific identities or analyze a group of identities based on standard criteria. The following filters are available on the **Identities** overview:
* **Search by name**: Locate specific individuals using a name-based search
* **Department filter**: View identities by organizational unit
* **Status filter**: Filter by Active or Inactive employment status
* **Access Profiles filter**: Find identities with specific profile assignments
* **Integrations filter**: Filter by source integration system
* **Policy filter**: View identities managed by specific policies
* **Workflows Triggered filter**: Identify identities that have triggered automation
* **Not in a Workflow**: Find identities outside automated workflows
#### **Identity Actions**
For each identity record, administrators can perform actions through the Actions menu:
* **View Details**: Access identity information, attribute history, and related accounts
* **Trigger Workflow**: Manually initiate a workflow in a policy
* **Request Access**: Launch an Access Request for additional access (requires Veza Access Requests).
See [Notification Templates for Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md) for customizing the Request Access Template.
* **Show in Graph**: Visualize identity relationships and access patterns
#### **View User Details**
Click on your selected identity to open the **Identity Details** view.
The following fields in the **Identity** **Details** view are populated with the current user's information:
* **Title:** The user’s position title.
* **Email**: The user's email address.
* **Providers**: A list of assigned integrations. When you click a specific provider, the **Integration** page opens, displaying the provider's detailed information, including its Entity Categories distribution.
* **Access Profiles**: A list of assigned Access Profiles to the identity. When you click on a specific profile, its detailed information page appears, displaying its status (either Draft or Published). You can also edit the Access Profile if needed.
* **Last Workflow Triggered**: The name of the workflow that was recently executed.
* **Primary**: The Primary identifier is configured (True or False) to be the authoritative attribute for matching or locating an identity.
* **Secondary Identities**: An associated name is connected to the primary identity.
* **ID**: The Identification number assigned to the primary identity.
* **Active**: The user’s identity is active if True. Otherwise, False when inactive.
* **Last Changed:** A time frame (in days, weeks, months) when the identity was last changed.
#### **Attribute Overrides**
When executing a policy where user attributes at the source of identity are incorrect, slow to update, or temporarily need adjustment, you can override the existing attribute with a different value until the issue is corrected. For more information, see [Identity Override Attributes](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/identities-overview/identity-override-attributes.md).
Here are some examples of incorrect or slow-to-update attributes:
* **Employee termination**: An employee has been terminated and needs immediate deprovisioning, but the termination status is not yet reflected at the source of identity
* **Role changes**: An employee has immediately changed roles and needs new birthright access, but the role change and the new manager haven't been updated in the source system
* **Contract extensions**: A contractor's end date has been extended, but the extension isn't reflected yet at the source of identity
* **Missing manager data**: The source of identity is missing a manager value, but this information is required for downstream application provisioning
* **Security incidents**: Immediate access restrictions are needed before HR systems can be updated
* **Temporary access grants**: Providing temporary access while permanent changes are processed
To create an **Override Value**, perform the following:
1. Select an identity by name.
2. Click **Details**.
3. Click **Properties** in the Details menu.
4. Click **Actions** (three dots icon)
5. Select **Create Override**.
6. The **Create Override** window appears. The **Property Name** and **Actual Value** fields are populated.
7. Enter an **Override Value**.
8. Click **Save**.
#### **Internal metadata**
The **Internal Metadata** tab on the Identity details view exposes Lifecycle Management's internal sync state for an identity. This is useful when troubleshooting stuck syncs, correcting identity mismatches, or forcing a resync after source-of-identity corrections.
For example, if an HR system initially created an employee with the wrong employee ID and the identity was already synced to a target system, Lifecycle Management retains the original mapping in its internal metadata. Correcting the employee ID at the source alone does not clear the stale mapping. The Internal Metadata tab allows administrators to clear the stuck mapping directly, so the next sync cycle picks up the corrected identity.
**Enabling the tab**
The Internal Metadata tab is hidden by default. To enable it:
1. Go to **Lifecycle Management > Settings > Identity Settings**.
2. Under **Display Settings**, enable the **Show internal metadata** toggle.
3. Click **Save**.
Enabling this setting requires the administrator role. Once enabled, the **Internal Metadata** tab appears as the last tab on all Identity detail views.
**Metadata sections**
The tab displays the following categories of internal state. Use the dropdown to select which sections to display. By default, Synced Entities, Action Run Info, and Workflow Failures are shown. Synced Relationships is available but not displayed by default.
| Section | Description |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Synced Entities** | Target system entities that are mapped ("stuck") to this identity. Each entry shows the datasource, entity type, and entity ID. When a sync creates or updates a target account, Lifecycle Management records the mapping here so future syncs update the same target entity. |
| **Action Run Info** | Per-action execution state, including the action name, current state, and last run timestamp. |
| **Workflow Failures** | Failure tracking per workflow, including first and last failure timestamps and the number of consecutive failures. |
| **Synced Relationships** | Target relationship bindings (such as group memberships) that Lifecycle Management has established for this identity. |
**Clearing metadata**
Action Run Info, Workflow Failures, and Synced Relationships each have a section-level **Clear** button that removes all stored metadata for that category. For Synced Entities, clear buttons appear on each individual entity mapping, allowing you to remove specific mappings without affecting others.
Clearing metadata does not modify the target system. It removes Lifecycle Management's record of the prior sync, so the next sync cycle treats the identity as if it has not been synced before and performs a full sync from the identity source.
A confirmation dialog appears before any clear operation. Clearing metadata should be done infrequently and only when the stored state is known to be incorrect.
**Audit logging**
All metadata edits are recorded as `IDENTITY_METADATA_EDIT` events in the [Activity Log](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/getting-started/activity-log.md). Each event includes the identity, the fields that changed, and the previous and new values.
### **Performing Actions on an Identity**
Click the overflow icon (three dots) to display options for performing actions on the identity. Next, click on the desired action:
* Trigger Workflow
* Request Access
* Show in Graph
#### **Trigger Workflow**
The Trigger Workflow option is a convenient way to test a specific user in a policy workflow. For example, you can test a new employee's identity in a joiner workflow to evaluate whether they have sufficient access to perform their duties.
Use the **Trigger Workflow** option to manually run a workflow for a specific user.
To trigger a workflow with a specific user, perform the following steps:
1. Select a workflow in the dropdown menu.
2. Click **Trigger** to run the workflow.
#### **Request Access for an Identity**
Requests Access allows for **additional** or **temporary** access grants, particularly when a user’s current access is insufficient for their duties.
Use the **Request Access** option in the Identity Details view to grant access to a specific user while reviewing their detailed information. You can grant access to the user through the following:
**Access Profiles option**
A collection of entitlements that are granted as part of the user’s identity lifecycle requirements. Access Profiles can:
* Define reusable collections of entitlements across multiple target systems by business roles, departments, or functions
* Automate consistent access provisioning
* Manage access profile types and their capabilities
See [Access Profile](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md) and [Access Profile Types](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/access-profile-types.md) for more information.
To grant an Access Profile, perform the following:
1. Click the **Access Profile** radio button.
2. The **Choose from Access Profile** window appears.
3. Enter a **Reason** for granting the Access Profile for the user.
4. Select an existing **Access Profile** from the dropdown menu.
5. Enter an **Expiration Time** in Hours or Days.
**App option**
An App refers to a target system, where user access is provisioned or deprovisioned as part of the identity lifecycle process.
To grant an App, perform the following:
1. Click the **Access Profile** radio button.
2. The **Request Grant Access** window appears.
3. Enter a **Reason** for granting the App for the user.
4. Select an existing **Integration** from the dropdown menu.
5. Use the arrows to select an **Expiration Time** in Days, where 0 means no expiration.
6. Click **Create**.
**Entitlements option**
Granting Entitlements to a user provides specific access permissions (roles, permissions, group memberships) required to perform their responsibilities.
**Note:** By granting Entitlements to a specific user, you pre-fill an Access Request with the appropriate configuration settings and policy.
To grant an Entitlement, perform the following:
1. Click the **Entitlements** radio button.
2. The **Request Grant Access** window appears.
3. Enter a Reason for granting the Entitlement for the user.
4. Select an existing **Integration** from the dropdown menu.
5. Based on the integration you selected, the **Target Entity Type** is automatically populated.
6. Use the arrows to select a **Target Entitlement**.
7. Use the arrows to select an **Expiration Time** in Days, where 0 means no expiration.
8. Click **Create**.
#### **Show in Graph**
Use the **Show in Graph** option to display a graph that represents all assigned Access Profiles, Apps, and Entitlements, including all associations.
This is a graphical representation of John Smith’s assigned access and entitlements to roles/groups.
---
# 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/features/lifecycle-management/identities-overview/identities.md?ask=
```
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.