Lifecycle Management

Lifecycle Management terms and definitions in the Veza platform.

Access Profiles

Access Profiles are reusable collections of entitlements that define what access should be granted to users during identity lifecycle events. Access Profiles enable you to group entitlements (groups, roles, and permissions) into versioned, managed bundles that can be assigned by Lifecycle Management policies and workflows. They support profile types, inheritance, versioning, and integration-specific limits, allowing you to model business roles, application entitlements, or multi-application access consistently across systems. Use Access Profiles to automate provisioning, maintain consistent birthright access, and manage profile membership and versions. Access Profiles help you: Define reusable collections of entitlements across multiple systems; Organize access by business roles, departments, or functions; Automate consistent access provisioning; Manage access profile types and their capabilities; View available integrations for access management.

Related documentation: Access Profiles

Action and Action Types

An Action is a unit of work or an operation that can be executed in response to identity-lifecycle or access events. It's essentially a provisioning/deprovisioning or remediation step that is triggered automatically by Policy Workflows. When a joiner, mover, or leaver event (or another trigger) occurs, Lifecycle Management will evaluate the actions that need to run (e.g., creating a user, assigning groups, removing entitlements). Actions are executed as part of a workflow when policy conditions are met. Actions can be combined in sequence, run for any identity matching the workflow, or be gated by action-level conditions. Action Types include: Sync Identities (executes synchronization to prevent provisioning error or duplication); Manage Relationships (add, update, or remove access relationships); Create Email (creates or enables an email); Deprovision Identity (disables or suspends a target user account while preserving data); Write Back Email (updates the Source of Identity with new email); Pause (delays workflow execution); Update ServiceNow Table (writes to ServiceNow tables); Send Notification (sends webhook notification); Create Access Review (queues or creates an Access Review); Reset Password (triggers password reset); Delete Identity (removes a target identity/account).

Related documentation: Action and Action Types

Activity Log

The Activity Log is Lifecycle Management's record of all provisioning operations, showing events, jobs, actions, and workflow tasks. The Activity Log tracks lifecycle operations to view atomic changes, job details, high-level actions, and workflow executions. Use filters, search, and timestamps to troubleshoot failures, verify changes, and monitor policy health. Activity logs are retained for audit purposes.

Related documentation: Activity Log

Attribute Transformer

Attribute Transformers modify and format user attributes when synchronizing identities between a source of identity and target systems. Attribute Transformers let you map source identity metadata into target account attributes, apply formatting functions (character case, substring, date formats, ASCII, remove chars, NEXT_NUMBER, IF/THEN/ELSE logic, etc.), and chain functions with pipelines. They can be set at the Policy or Action level (common transformers reusable across workflows), support Continuous Sync per attribute, and handle fallbacks and uniqueness during provisioning. Attribute Transformers can: Change character case; Extract substrings; Format dates; Convert to ASCII; Remove characters; Generate numbers (incrementing); Chain functions; Use IF/THEN/ELSE logic.

Related documentation: Attribute Transformer

Birthright

Birthrights are the default entitlements granted to a user based on their Business Role. Birthright entitlements are the application-specific groups, roles, or permissions (defined in Access Profiles) that users automatically inherit when assigned a Business Role. In Lifecycle Management, you map Business Roles to Access Profiles so employees receive the correct, role-based access during onboarding, moves, and throughout their lifecycle; these defaults drive automated provisioning and deprovisioning. Benefits of Birthright: Faster onboarding - new users get access immediately; Consistency - ensures all users in similar roles get the same access; Security - prevents over-provisioning by limiting access to only what's necessary; Automation - removes manual steps in user provisioning.

Related documentation: Birthright

Common Transformer

Common transformers are reusable, Policy-level attribute templates that define how to format and source target identity attributes for Lifecycle Management workflows. Common transformers let you define one or more destination-attribute rules (Formatters, Pipelines, and Continuous Sync settings) for a given target entity type and reuse them across Sync or Deprovision actions. You can configure a common transformer in Policies (Edit Policy > Common Transformers), which can be overridden by action-level transformers, and their order controls precedence. You create common transformers to ensure consistent naming, reduce errors, and simplify policy maintenance.

Related documentation: Common Transformer

Dry Run

Dry Run is a simulation mode that evaluates a lifecycle policy against an identity without making any real changes. Dry Run evaluates identity attributes, matches workflows, and simulates the actions and Access Profile changes that would be run, then returns a comprehensive report of "Workflows Run" and "Potential Changes" without touching the target systems. Use Draft versions or set a policy to DRY_RUN to test changes; start Dry Runs from a Policy or from an Identity's actions menu.

Related documentation: Dry Run

Entitlements

Entitlements are specific access grants (such as group membership, role assignment, permission, or similar objects) that Lifecycle Management can create, synchronize, and manage for an identity. Lifecycle Management models entitlements as concrete target-system objects (for example: an Active Directory group, an Okta group, an AWS permission set, a SCIM group, or a local resource permission). Entitlements are grouped into Access Profiles for reuse, which are used by Lifecycle Management policy workflows/actions (such as Manage Relationships, Sync Identity, and Deprovision) to provision or revoke access. Additionally, Access Profiles are utilized in Access Requests and Access Reviews for governance purposes. Entitlements Usage: Access governance - ensures users only have needed access (least privilege); Policy enforcement - policies grant or remove entitlements based on identity attributes; Audit & compliance - provides visibility into who has access and why; Lifecycle automation - entitlements are dynamically assigned/removed as users join, move, or leave.

Related documentation: Entitlements

Entity Types

Entity Types refer to the various kinds of entities in Lifecycle Management processes. Lifecycle Management records and works with different entity types when running policies, workflows, actions, jobs, and events. They drive which actions and transformers apply, and how integrations map attributes and relationships across systems. Examples of Entity Types: User (human identity like employee or contractor); Service Account (non-human identity for apps/scripts); Group (collection of users); Role (predefined set of permissions); Permission (specific rights to perform actions); Application (integrated system like Salesforce, GitHub, AWS); Resource (object within a system like S3 bucket or DB table); Policy (access control logic); Entitlement (grant of permission or role to an identity).

Related documentation: Entity Types

Events

Events are atomic records of individual changes made by Lifecycle Management actions. Lifecycle Management stores Events in the Activity Log; each Event represents a change resulting from a successful job, such as ADD_RELATIONSHIP, REMOVE_RELATIONSHIP, or SYNC_IDENTITY. Events are useful for verifying specific changes, troubleshooting errors, and auditing provisioning activity. The Events view shows columns such as: Event Type, Timestamp, Success, Identity, Entity Name, Entitlement Entity, Message.

Related documentation: Events

Identity

An Identity is the top-level representation of individual users (human) and digital accounts (non-human) within your organization's systems, used by Lifecycle Management to manage lifecycle events (provisioning, modifying, deprovisioning). Identities represent employees, contractors, or external partners and are populated by integrating a Source of Identity (SOI). Policies and workflows utilize identity attributes and syncs (Sync Identities, Manage Relationships, Deprovision Identity) to execute joiner/mover/leaver and just-in-time access flows. You can view, search, override attributes, trigger workflows, and request access for one or many identities. Identity's key points: Human and non-human identities (users, service accounts, machine identities); Joiners, Movers, Leavers (JML) lifecycle model; Attributes & metadata associated with each identity; Audit/traceability for compliance and forensic analysis.

Related documentation: Identity

Identity Sync

Identity Sync synchronizes and deduplicates user identities across target systems during provisioning or identity synchronization workflows. Identity Sync prevents provisioning errors (like duplicate usernames or emails) by locating and updating existing target accounts instead of creating duplicates. It supports continuous synchronization of mapped attributes, configurable modes (e.g., "Sync on changes only" or "Always sync"), and is used in Sync Identities actions for targets such as Okta and Active Directory with attribute mappings and fallback formatters. It's an action within Lifecycle Management used during provisioning or identity synchronization workflows. If your target system already has an identity with a given attribute (e.g., a username or email is already in use), Lifecycle Management can automatically generate an alternative value instead of failing (e.g., "jsmith1", "jsmith2"). These alternatives are generated by applying fallback formatters (transformers), such as NEXT_NUMBER (which appends an incrementing number) or RANDOM_ALPHANUMERIC_GENERATOR (which appends a random string), to ensure that each provisioned identity remains unique across systems.

Related documentation: Identity Sync

Notifications

Notifications can be configured to be sent via either email or webhook for LCM workflow events. Notifications inform stakeholders or external systems when lifecycle events occur (create/sync/delete identity, entitlement changes, access request updates, failures, etc.). You can configure notifications in a policy's Notifications settings by adding an Email or Webhook, choosing the event type and success/failure status, selecting recipients or a Veza Action, and optionally customizing templates via the Notification Templates API.

Related documentation: Notifications

Policy

A Policy is a versioned rule set that defines workflows, conditions, and actions to automate identity provisioning and deprovisioning for a given identity source. Policies contain metadata (name, description, and primary identity source) and a Policy Configuration, which is composed of one or more workflows. Workflows include trigger conditions (SCIM filters or time-based rules), success conditions, actions (provision, deprovision, manage relationships, notifications, etc.), and optional transformers or lookup tables to shape attributes. Policies are versioned (draft/published/retired) and have operational states, such as INITIAL, DRY_RUN, RUNNING, and PAUSED, to control testing and activation. Use a separate policy for each identity source (with optional additional sources), maintain distinct workflows for Active/Inactive scenarios (joiner/mover/leaver), and validate changes with a Dry Run or draft version before switching the policy to a RUNNING state.

Related documentation: Policy

Source of Identity (Primary and Secondary)

Source of Identity (SOI) is the authoritative system that provides user records used to trigger Lifecycle Management policies. Source of Identity systems are the primary data sources (such as HRIS, IDP, and CSV/OAA payloads) that Lifecycle Management monitors for user changes. Policies select a Primary Identity Source to detect joiner/mover/leaver events and run workflows. You can add Additional Identity Sources for enrichment, but the Primary Identity Source is the authoritative trigger. Primary Sources: Must be the same entity type (e.g., Worker). They create core LCM identities, are treated as authoritative for creation/updates, and any changes in a primary source trigger workflows. Secondary Sources: Used for enrichment and correlation. They can supply additional attributes that augment primary identity records. Secondary sources support two modes via the only_enrich_existing flag: true (enrichment-only - never creates new LCM identities) or false (hybrid - may create new Policy Identities if no matching primary identity exists). Secondary sources also enable cross-system correlation through custom matching (e.g., email, IDs, composite keys).

Related documentation: Source of Identity (Primary and Secondary)

Unique Identifiers

A Unique Identifier is the attribute Veza uses to locate the correct target entity when provisioning or deprovisioning identities. Lifecycle Management allows you to choose which attribute(s) act as a Unique Identifier (for example, username, email, or employee_id) so that Sync Identity and Deprovision Identity actions update the intended accounts. This is configured at the action level (and in Common Transformers) and can use custom properties extracted from integrations, enabling reliable matching even with non-standard naming or custom directory schemas. You can configure the Unique Identifier in your Sync/Deprovision action (or integration custom property) to ensure correct target matching.

Related documentation: Unique Identifiers

User Attributes

User attributes are the identity properties from a source of identity used by Lifecycle Management to drive provisioning, synchronization, and policy logic. User attributes are source-of-truth fields (such as first name, last name, email, title, department, manager, hire/termination dates, employee ID, employment status, etc.) that Lifecycle Management reads, transforms, and maps into target account attributes. They can be continuously synced, transformed with transformers/pipeline functions, or temporarily overridden for policy execution.

Related documentation: User Attributes

Veza Actions

Veza Actions are outbound integrations (webhooks, email, and built-in targets) that trigger external notifications or automations, sending Veza events to external systems. Veza Actions enable you to configure events to downstream targets, allowing you to create tickets, post Slack messages, send emails, or invoke custom listeners. You can assign Veza Actions to Rules, Access Review configurations, or individual reviews. Built-in targets include Slack webhooks, Jira, ServiceNow, email, and a generic webhook; payloads include review and row details. Veza Actions examples include posting alerts to Slack channels, sending emails, creating Jira or ServiceNow tickets, and sending custom JSON webhooks for events such as row approval/rejection or review completion. They also support Lifecycle Management auto-revocation (removing access when rows are rejected) and can be assigned to Access Review events (reassigning the reviewer, approving the row, rejecting the row, or completing the review).

Related documentation: Veza Actions

Workflows

Workflows are conditional sequences of actions inside a Lifecycle Management policy that run for identities meeting specific trigger criteria. Workflows enable you to automate joiner, mover, and leaver processes by evaluating trigger conditions (attribute, time-based, or relationship triggers) and executing ordered actions (for example, Sync Identities, Manage Relationships, Deprovision). A single policy can contain multiple workflows (e.g., Active vs Inactive) with priority, continuous sync controls, delays, and action-level conditions. Use Dry Run to simulate which workflows and actions would run for an identity.

Related documentation: Workflows

---

← Back to Glossary