Overview

This page covers the integrations that power Lifecycle Management workflows and can act as identity sources for LCM policies, and target applications that can be provisioned or deprovisioned.

Enabling provisioning on an integration also makes it available to other Veza products that use write-back capabilities, including Access Intelligence (Disable Accounts) and Access Requests. The integration tables below represent the validated, production-ready set for Lifecycle Management specifically.

Veza supports three primary implementation pathways:

1. Native Integrations: Direct API-based provisioning with out-of-the-box support (see validated integrations below)

2. SCIM 2.0 Protocol: Standards-based provisioning for any SCIM-compliant application

3. OAA Write Framework: Veza's Open Authorization API (OAA) extends write-back support to applications not natively integrated with the Veza platform

This architecture means that nearly any existing Veza integration can be enabled for provisioning. The validated integrations listed below represent tested, production-ready configurations. For additional integration support, contact your Customer Success Manager.

Identity sources are authoritative systems that provide information about user identities. While Veza does not require write permissions to the identity source of truth, some of these integrations are also supported as provisioning targets. Integrations can also allow write-back of a user's newly created email address to the user's record in the source of identity as part of the initial provisioning workflow.

Veza supports leading HR systems, IDPs and directory services, ITSM platforms, payroll systems, custom applications, and flat files:

The following integrations are validated as provisioning targets for Lifecycle Management workflows. Enabling provisioning on an integration enables actions (create, sync, deprovision, manage relationships) that can be triggered from LCM policies and from other Veza products.

Validated Integrations

The following table lists the out-of-the-box, Veza-validated target application integrations.

Other Supported Integrations

For any Veza-supported application not listed above, contact your Customer Success Manager for more details on how to enable the specific Veza integration for use with provisioning as a target application for provisioning and de-provisioning.

Custom REST Actions

Veza provisioning supports Custom REST Actions that enable HTTP requests to external APIs and services as part of automated workflows. This action type provides integration with custom applications, webhooks, and any REST-based service that supports identity management operations.

Custom REST Actions extend provisioning support to virtually any system with an accessible API, enabling use cases such as triggering custom workflows, notifying external systems, or coordinating provisioning sequences across multiple downstream applications.

An Insight Point is required to enable provisioning operations and identity discovery for systems that Veza cannot access directly, such as an on-premises application server behind a firewall. The Insight Point is a lightweight connector that runs in your environment, enabling secure gathering and processing of authorization metadata for provisioning tasks.

A Veza Insight Point is typically deployed as a Docker container or VM OVA, running within your network for metadata discovery and provisioning job execution. This ensures secure communication between your environment and Veza.

For deployment instructions, refer to the .

You can configure extraction intervals for your integrations to ensure data is regularly updated for provisioning workflows.

1. Go to Veza Administration > System Settings

2. In the Pipeline > Extraction Interval section, set the global extraction interval

3. To override the global setting for specific integrations, use the Active Overrides section

Available extraction intervals are:

• Auto (hourly, but may take longer when the extraction pipeline is full)

• 15 Minutes

• 1 Hour

• 6 Hours

To manually trigger an extraction:

1. Go to Integrations > All Data Sources

2. Search for the desired data source

3. Select Actions > Start Extraction

Note: Custom application payloads are extracted after the payload is pushed to Veza using the Open Authorization API.

To enable provisioning for a specific integration:

1. Open the Integrations page (in the Featured section of the navigation sidebar), or Lifecycle Management > Integrations (in the Products section).

2. Search for the integration you want to enable and open its settings.

3. Check the Enable usage for Provisioning checkbox, then click Save Configuration.

After saving, the integration shows Enabled in the Lifecycle Management column on the Integrations overview.

To verify the health of the provisioning data source:

1. Open Lifecycle Management > Integrations (in the Products section of the navigation sidebar), or the main Integrations page (in the Featured section)

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Many identity source systems have API rate limits that can affect extraction timing. Avoid forcing repeated extractions within short time windows (typically 5 minutes) to prevent API errors that delay workflow execution.

For systems using custom or user-defined fields (UDFs), maintain clear documentation of:

• Field purpose and mapping

• Expected data formats and validation rules

• Which fields are used in workflow trigger conditions

This documentation ensures consistency when fields are added or modified.

Understand the data retention policies of your identity sources, particularly for terminated employees or contractors. Some systems retain terminated records for limited periods (e.g., 90 days), which affects leaver workflow design. Plan workflow timing to ensure LCM can process records before they're purged from the source system.

Changes to core identity fields can break LCM workflows. Coordinate with system administrators before modifying:

• Unique identifiers (employee ID, username)

• Employment status fields

• Date fields (hire date, termination date)

• Location or department identifiers

Communicate planned changes in advance and test in sandbox environments before applying to production identity sources.

For more information:

• Refer to individual integration documentation for detailed provisioning capabilities

• Consult the Veza documentation for troubleshooting and best practices

• Contact Veza support for assistance with enabling or configuring provisioning for your integrations

Overview

Veza can automate user provisioning and de-provisioning for any application that uses the Open Authorization API (OAA) for data gathering and authorization modeling, and exposes SCIM-compliant endpoints for user and group management.

This enables organizations to:

• Use your application's existing SCIM endpoints for automated provisioning operations

• Model complex authorization structures using OAA's flexible templates (applications, resources, permissions, custom properties) for Access Graph visibility, Access Reviews, and other Veza features.

• Gather authorization metadata using a variety of methods (custom connectors, APIs, manual JSON payloads, CSV files)

See for details on each action type.

1. Administrative access in Veza to configure the integration

2. An existing integration in Veza with at least one successful extraction

3. Your custom application must expose SCIM 2.0-compliant endpoints; see below

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for your custom OAA application integration

3. Check the box to Enable usage for Lifecycle Management

To verify the configuration:

1. Open Lifecycle Management > Integrations

2. Search for the integration and click to view details

3. In the Properties panel, verify Lifecycle Management Enabled is active

There are several potential ways to integrate a custom application for automated lifecycle management and access requests:

1. External SCIM for Open Authorization API: You may build your OAA integration using the custom application template and leverage dedicated SCIM endpoints for user and group management. This is useful when you need full control over how authorization metadata is represented in the Veza Access Graph:

   • Your application supports SCIM, and you want to model a wider range of authorization entities and metadata (e.g., credentials, resources) than the Veza SCIM integration supports.

   • You already have a custom OAA integration and want to add provisioning capabilities using SCIM.

This document describes how to enable External SCIM for an Open Authorization API integration, and supported actions.

Data Gathering (OAA):

You will need to design and build a custom integration to publish information about the application to the Veza Access Graph:

• The payload can include local users, groups, permissions, resources, and complex authorization relationships

• Data can be gathered from any source: APIs, databases, configuration files, etc.

See the rest of the Open Authorization API documentation for examples and best practices when designing and deploying custom integrations.

Lifecycle Management (SCIM):

You can enable the SCIM connection at the custom provider level:

• Setting provisioning: true and external_lifecycle_management_type: SCIM for the custom provider enables Veza to use your application's SCIM endpoints for provisioning

• Provide SCIM connection information and credentials (configuration_json)

• Veza maps lifecycle actions to SCIM operations (

Important: When configuring a custom application for SCIM integration, the OAA payload structure (Application template) and SCIM configuration serve different purposes:

• The OAA Payload (push_application() or API push) defines local users, groups, permissions, and resources used for visibility and authorization modeling in Veza, and can be updated independently.

• The SCIM Configuration (configuration_json) for the custom provider defines how to connect to SCIM endpoints (including authentication, URL, and endpoint paths), and is used only for lifecycle management and access request operations.

Both must be consistent (describe and contain the same users and groups), but are configured separately.

Your application must expose SCIM 2.0 compliant endpoints with the following operations:

User Management:

• GET /Users - List and filter users

• GET /Users?filter=userName eq "{username}" - Query users by userName

• POST /Users - Create new users

Group Management:

• GET /Groups - List groups

• GET /Groups/{id} - Retrieve specific group by ID

• POST /Groups - Create new groups

Note: If the Users and Groups APIs are not at the standard /Users and /Groups paths, you can specify alternate endpoint paths in the configuration.

Your SCIM API must support one of the following authentication methods:

• Bearer Token: API token passed in Authorization: Bearer {token} header

• Basic HTTP Authentication: Username and password passed in Authorization: Basic {credentials} header

The authentication credentials must have both read and write permissions to the SCIM endpoints.

To synchronize custom attributes beyond the standard SCIM user schema:

• Expose a GET /Schemas endpoint that returns SCIM schema definitions

• Enable schema fetching in your configuration (see Configuration section)

External SCIM for Lifecycle Management is configured via the Veza REST API.

Create a Custom Provider that uses external SCIM endpoints specifically for lifecycle management:

Required Fields

Configuration JSON Parameters

The configuration_json field contains SCIM endpoint connection details used only for provisioning operations. It does not affect your OAA payload structure.

* One of scim_token or the username/password pair is required for authentication.

Example Configuration with Bearer Token:

Example Configuration with Basic Authentication:

Push the OAA Application Payload as normal. See the for details.

Veza creates entities in Access Graph based on the OAA payload, which can be targeted in lifecycle management operations:

• local_users in your Application template → Users to provision via SCIM

• local_groups in your Application template → Groups to manage via SCIM

Entity types are named according to the following pattern:

• User Entity Type: OAA.{application_type}.User

• Group Entity Type: OAA.{application_type}.Group

Where {application_type} is the value you specify in your OAA Application template when building the payload. For example, if the application is defined:

The resulting entity types are:

• OAA.CustomerPortal.User

• OAA.CustomerPortal.Group

When Veza provisions users via SCIM, transformers can map attributes from your policy source of identity to SCIM properties:

If the SCIM service exposes a /Schemas endpoint and you enable scim_extension_schemas: true, Veza can synchronize custom extension attributes beyond the standard SCIM user schema. Extension attributes are mapped using the schema URN as defined by your SCIM implementation.

The following SCIM operations are performed when Lifecycle Management actions execute:

Create a new user in the target application.

SCIM Operation:

The SCIM endpoint creates the user and returns the user object with an assigned id.

Updates an existing user's attributes (one-time or continuously).

SCIM Operations:

1. Query for existing user:

2. Update the user:

Remove access when a user leaves the organization or changes roles. The user account is deactivated, but data is preserved.

SCIM Operation:

Deprovision sets active=false, which disables login but preserves the user record.

Permanently remove a user account.

SCIM Operation:

Grant a user access via group membership.

SCIM Operations:

1. Retrieve group details:

2. Add user to group:

Revoke a user's access by removing group membership.

SCIM Operation:

Creates a new group so that it can be granted as an entitlement.

SCIM Operation: