Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Overview of supported Lifecycle Management integrations in Veza, with capabilities and supported actions for target applications and sources of identity.
This document provides an introduction to the integrations supported by Veza Lifecycle Management (LCM), including capabilities and supported actions. These integrations enable automated identity and access management workflows across a wide range of identity sources and target applications.
Lifecycle Management supports three primary implementation pathways:
Native Integrations - Direct API-based provisioning with out-of-the-box support (see validated integrations below)
SCIM 2.0 Protocol - Standards-based provisioning for any SCIM-compliant application
OAA Write Framework - Veza's Open Authorization API (OAA) can support provisioning and deprovisioning for applications not natively supported by the Veza platform.
This architecture means that nearly any existing Veza integration can be enabled for Lifecycle Management. 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.
Lifecycle Management supports leading HR systems, IDPs and directory services, ITSM platforms, payroll systems, custom applications, and flat files:
The entire catalog of Veza application integrations is Lifecycle Management-ready. Target application support in Lifecycle Management leverages Veza's existing native and OAA-based integrations, plus an intelligent shim layer to provide support for provisioning and de-provisioning.
As such, target application support in Lifecycle Management can be enabled for nearly every Veza-supported integration.
Validated Integrations
The following table lists the out-of-the-box, Veza-validated target application integrations for Lifecycle Management.
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 Lifecycle Management as a target application for provisioning and de-provisioning.
Custom REST Actions
Lifecycle Management supports Custom REST Actions that enable HTTP requests to external APIs and services as part of LCM workflows. This action type provides integration with custom applications, webhooks, and any REST-based service that supports identity management operations.
Custom REST Actions extend LCM 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 Lifecycle Management 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 LCM tasks.
A Veza Insight Point is typically deployed as a Docker container or VM OVA, running within your network for metadata discovery and LCM 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 Lifecycle Management processes.
Go to Veza Administration > System Settings
In the Pipeline > Extraction Interval section, set the global extraction interval
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:
Go to Integrations > All Data Sources
Search for the desired data source
Select Actions > Start Extraction
Note: Custom application payloads are extracted after the payload is pushed to Veza using the Open Authorization API.
To enable Lifecycle Management for a specific integration:
Browse to the main Veza Integrations page, or go to Lifecycle Management > Integrations
Search for the integration you want to enable
Toggle the Lifecycle Management option to Enabled
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
For more information:
Refer to individual integration documentation for detailed LCM capabilities
Consult the Lifecycle Management user guide for troubleshooting and best practices
Contact Veza support for assistance with enabling or configuring LCM for your integrations
12 Hours
1 Day
2 Days
3 Days
7 Days
30 Days
This guide describes how to enable and configure Exchange Server for Lifecycle Management in Veza, including supported capabilities and configuration steps.
Supports the creation of email accounts for users within Exchange Server.
Entity Type: Exchange Server Users
Attributes Available for Configuration:
Identity (Required)
Example Use Cases:
Create email accounts for new employees joining the organization
Assign email aliases to users to facilitate communication
Find the Exchange Management Shell shortcut in the Start Menu
Right-click > More > Open File Location
Right-click the shortcut icon > Properties
Open IIS Manager and create a new application pool
Name the application pool
Configure the application pool:
Add the application to "Default Web Site"
Configure the application:
Set alias to "VezaProvisioner"
Install the VezaProvisioner.msi installer provided by Veza support on the Exchange Server. This component handles email address creation for users provisioned in Active Directory.
Go to Configurations > Integrations
Click Add New and select Exchange Server
Complete the following fields:
After configuration, the Exchange Server integration will be available for use in Lifecycle Management policies, specifically for the Create Email action. This action can be used in workflows for new employee onboarding or other scenarios requiring email account creation.
Configuring the Coupa Contingent Workforce integration for Veza Lifecycle Management.
The Veza integration for Coupa Contingent Workforce (CCW) enables automated identity synchronization as a source of truth for contingent worker lifecycle management. Coupa CCW serves as an authoritative source for contingent worker information that can be synchronized with other systems in your environment.
This document includes steps to enable the Coupa CCW integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration and Customer Integration Admin privileges in Coupa CCW.
Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.
Verify your Coupa CCW integration has completed at least one successful extraction
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a Coupa CCW integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Coupa CCW data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Coupa CCW in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Coupa CCW can serve as a source for identity information in Lifecycle Management . Contingent worker identity details are synchronized from Coupa CCW with changes propagated to connected target systems.
Important: Coupa CCW is a source-only integration for Lifecycle Management. It provides authoritative identity information but cannot be used as a provisioning target.
The integration supports the following lifecycle management :
As a source-only system, Coupa CCW provides:
Contingent worker identity information synchronized to downstream systems
Organizational structure data (Account Segments, Cost Centers, Departments)
Employment status and contract details for lifecycle decisions
When a new contingent worker is added to Coupa CCW:
Identity Sync: Coupa CCW provides worker details to Veza Lifecycle Management
Access Provisioning: Based on department, cost center, and role, appropriate access is granted in target systems
Manager Assignment: Hiring manager relationships are established for approval workflows
When a contingent worker's status changes (contract end, role change):
Status Detection: Coupa CCW reflects updated employment status
Access Review: Lifecycle policies evaluate continued access needs
De-provisioning: If terminated, appropriate access removal is triggered in target systems
When a contingent worker transitions to full-time employee:
Status Update: Employment type change is detected in Coupa CCW
Access Migration: Existing access is evaluated and potentially expanded
System Updates: Worker identity is updated across all connected systems
ccw.contingent_workers - For accessing contingent worker data
Copy the Target field value
Note the two important paths from the target:
PowerShell Path: (e.g., C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)
Remote Exchange Path: (e.g., C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1)
Right-click > Advanced Settings
Under Process Model, set the Identity
Select the application pool created above
Configure authentication:
Disable Anonymous Authentication
Enable Basic Authentication
Insight Point
Select if using an Insight Point to access Exchange Server
Name
Friendly name for the integration
Instance URL
https://<exchange_server_host>/VezaProvisioner
Username
Domain username with required Exchange permissions
Password
Password for the account
PowerShell Path
Path to PowerShell.exe noted in step 1
Remote Exchange Path
Path to RemoteExchange.ps1 noted in step 1
Enable Lifecycle Management by checking Enable Lifecycle Management
Save the configuration
Configuring the Atlassian Cloud integration for Veza Lifecycle Management.
The Veza integration for Atlassian Cloud enables automated user lifecycle management, with support for user provisioning and deprovisioning, group membership management, and attribute synchronization across Atlassian Cloud Admin, Jira Cloud, Confluence Cloud, and Bitbucket Cloud.
This document includes steps to enable the Atlassian Cloud integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
Before enabling Lifecycle Management for Atlassian Cloud, ensure you have the necessary access and configuration in place. You'll need administrative access in both Veza and Atlassian Cloud to complete the setup process.
Veza Requirements:
Administrative access to configure integrations
An existing that has completed at least one successful extraction
Atlassian Cloud Requirements:
Administrative access to manage API keys and SCIM configuration
An active SCIM directory configured in your Atlassian Cloud organization
Proper API permissions for both SCIM and Atlassian Cloud Admin APIs
The following parameters are required to enable lifecycle management operations:
The integration automatically extracts the directory ID from your SCIM URL and uses it alongside the organization ID to coordinate user and group operations.
Optional Parameters: If you're also using the integration for discovery operations (viewing Jira projects, Confluence spaces, and Bitbucket repositories in Veza), you'll need product_token and product_user. These parameters are not required for lifecycle management operations and can be omitted if you're only performing user provisioning and group management.
Complete the following steps in Veza to enable and configure Lifecycle Management for your Atlassian Cloud integration.
Enable Lifecycle Management:
Navigate to the Integrations overview in Veza
Locate your Atlassian Cloud integration (or create a new one if needed)
Check the box to Enable usage for Lifecycle Management
Configure Data Synchronization:
Configure the extraction schedule to ensure Atlassian Cloud user and group data remains current. Go to Administration > System Settings, then navigate to Pipeline > Extraction Interval. Set your preferred interval for data synchronization, or create a custom override specifically for Atlassian Cloud in the Active Overrides section if you need more frequent updates than your default schedule.
Verify Configuration:
After enabling Lifecycle Management, verify the integration is functioning correctly by navigating to Lifecycle Management > Integrations (or the main Integrations overview). Locate your Atlassian Cloud integration and click its name to view details. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled to check the health status.
Atlassian Cloud can be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management :
The Sync Identities action creates new user accounts or updates existing ones in Atlassian Cloud. User provisioning occurs through the SCIM directory API, which ensures that email addresses remain unique across your Atlassian organization. When you create or update a user, Veza automatically establishes cross-service connections between the Cloud Admin user account and their corresponding accounts in Jira, Confluence, and Bitbucket.
Supported User Attributes:
The active status is managed automatically during provisioning and deprovisioning operations and is not available as a sync attribute. When you sync user attributes, Veza translates them to the appropriate SCIM fields shown in the table above before sending them to Atlassian's SCIM API.
The Manage Relationships action controls group memberships for users across Atlassian Cloud. You can add users to groups or remove them, with changes synchronized across Atlassian Cloud Admin and all associated products (Jira, Confluence, and Bitbucket). All membership changes are tracked automatically for audit purposes, providing visibility into access modifications over time.
Atlassian Cloud groups can control various types of access, including product-level permissions (such as access to specific Jira projects or Confluence spaces), administrative roles within Atlassian Cloud Admin, site-wide permissions and policies, and integration settings with external identity providers. When you modify a user's group memberships through Veza, these changes apply consistently across all products where the group has assigned permissions.
Important: Groups must already exist in both the SCIM directory and Atlassian Cloud Admin before you can assign users to them. The integration does not support creating or deleting groups. See for more details.
The Deprovision Identity action safely removes user access while preserving audit trails for compliance. When you deprovision a user, their account is deactivated through the SCIM API and all group memberships are automatically removed across Atlassian Cloud Admin, Jira, Confluence, and Bitbucket. While the user can no longer access any Atlassian products, their account information and cross-service connection history are preserved to maintain audit trails and historical visibility for compliance reporting.
The Delete Identity action permanently removes the user account and associated data from Atlassian Cloud. When you delete a user, their account is permanently deleted through the SCIM API, not just deactivated. Unlike deprovisioning, this operation cannot be reversed and should be used with caution only when permanent removal is required.
The following operations are not supported in the current implementation:
User Logout: Cannot force user logout from Atlassian products
License Management: Cannot remove specific licenses from users
Device Management: Cannot manage or remove personal devices
Managing group memberships in Atlassian Cloud requires coordination between the SCIM directory and Atlassian Cloud Admin.
Key requirements and limitations:
Groups must already exist in both systems: You can only assign users to groups that are present in both the SCIM directory and Atlassian Cloud Admin. The integration does not support creating or deleting groups.
Display name matching: When modifying group memberships, Veza uses display name matching to identify the corresponding group in each system.
Automatic ID mapping: The integration automatically maps the correct SCIM group ID and Atlassian group ID for each operation.
The Atlassian Cloud integration uses a dual-API architecture to provide comprehensive lifecycle management capabilities.
User provisioning, deprovisioning, and attribute updates are handled via Atlassian's SCIM API, ensuring email uniqueness and maintaining user account consistency.
Group membership management uses the Atlassian Cloud Admin API, which provides the functionality to add and remove users from groups across all products. ID Mapping and Coordination:
To maintain consistency across systems, the integration performs complex ID mapping between SCIM identifiers and Atlassian identifiers. SCIM User IDs are mapped to Atlassian Account IDs, and SCIM Group IDs are mapped to Atlassian Group IDs. The integration automatically extracts the directory ID from your SCIM URL and uses your organization ID to coordinate these operations. This ensures that changes made through Veza are reflected accurately in both the SCIM directory and across all Atlassian products.
Automate the provisioning of new employees into Atlassian Cloud:
Create User Account: New user account is created via SCIM with basic profile information
Assign Base Groups: User is added to organization-wide groups for general access
Product Access: User is granted access to specific products (Jira, Confluence, Bitbucket) based on role
Handle employee role changes and access updates:
Update User Attributes: User profile information is updated to reflect new role
Remove Previous Access: User is removed from role-specific groups and permissions
Grant New Access: User is added to groups appropriate for their new role
Safely remove access when employees leave:
Deactivate Account: User account is disabled via SCIM
Remove All Groups: User is removed from all groups and permissions
Revoke Product Access: Access is revoked across Jira, Confluence, and Bitbucket
Configuring Google Cloud for Veza Lifecycle Management
The Veza integration for Google Cloud enables automated user provisioning, access management, and de-provisioning capabilities for Google Workspace. This integration allows you to synchronize identity information, manage group memberships, and automate the user lifecycle from onboarding to offboarding.
name.formatted
Combined first and last name
display_name
No
String
User's display name
displayName
How the user appears in Atlassian products
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities
✅
DELETE_IDENTITY
Permanently deletes the user account and associated data
✅
SCIM URL (scim_url)
The SCIM endpoint URL for your Atlassian organization
User provisioning and deprovisioning
SCIM Token (scim_token)
Authentication token for SCIM API access
Authenticates user lifecycle operations
Admin API Key (admin_api_key)
API key for Atlassian Cloud Admin API
Group management and ID mapping
SCIM Organization ID (scim_organization_id)
Your organization's SCIM identifier
Yes
String
User's email address
userName
Unique identifier across the organization
name
No
String
Coordinates operations across APIs
User's full name
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships for identities
✅
DEPROVISION_IDENTITY
Safely removes or suspends access for identities
✅
SOURCE_OF_IDENTITY
Google Cloud can act as a source system for identity lifecycle policies
✅
This document includes steps to enable the Google Cloud integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration and grant API scopes in Google Cloud.
Ensure you have an existing Google Cloud integration in Veza or add a new one for use with Lifecycle Management.
Verify your Google Cloud integration has completed at least one successful extraction.
The Google Cloud integration will need the following additional API scopes:
https://www.googleapis.com/auth/admin.directory.user - Required for user management operations
https://www.googleapis.com/auth/admin.directory.group - Required for group management operations
https://www.googleapis.com/auth/admin.directory.domain
In Veza, go to the Integrations overview
Search for or create a Google Cloud integration
Check the box to Enable usage for Lifecycle Management
Configure the service account with appropriate permissions:
Users > Read/Write
Groups > Read/Write
Organization Units > Read
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Google Cloud can serve as a source for identity information in Lifecycle Management Policies. User identity details are synchronized from Google Cloud with changes propagated to connected systems.
Google Cloud can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management Actions:
Primary action for user management (creating or updating users):
Entity Types: Google Workspace User
Create Allowed: Yes (New user identities can be created if not found)
The following attributes can be synchronized:
Controls relationships between users and Google Workspace groups:
Supported Relationship Types: Google Workspace Groups
Assignee Types: Google Workspace Users
Supports Removing Relationships: Yes
Both adding and removing group memberships are supported:
Add users to specific Google Workspace groups based on department or role
Remove access when roles change or users leave
Maintain consistent group membership based on organizational structure
When a user is deprovisioned:
Entity Types: Google Workspace User
De-provisioning Methods: Suspend user (preserves user data while preventing access)
User is suspended in Google Workspace
Access to resources is removed
Account information is preserved for audit purposes
Google Cloud can serve as a source system for identity lifecycle policies, where changes to Google Workspace users trigger workflows in other systems.
To create a workflow for onboarding new employees:
Create a policy with your source of identity (e.g., Workday or CSV upload)
Configure a workflow for new employees
Add a Sync Identities action to create Google Workspace users:
Add a Manage Relationships action to assign appropriate groups:
Condition: department eq "Engineering"
Add to: "Engineering Team" group
Condition: department eq "Sales"
To create a workflow for departing employees:
Create a policy with your source of identity
Configure a workflow with condition: active eq false
Add a De-provision Identity action:
Entity Type: Google Workspace User
Method: Suspend
Remove All Relationships: Yes
Configuring the GitHub integration for Veza Lifecycle Management.
The Veza integration for GitHub enables automated user lifecycle management, with support for user provisioning, team membership management, and account deprovisioning.
This document includes steps to enable the GitHub integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration and site administrator privileges in GitHub Enterprise Server.
Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.
Verify your GitHub integration has completed at least one successful extraction
Important: GitHub LCM operations use Admin API endpoints that require site administrator privileges. These operations are typically available in GitHub Enterprise Server environments, not GitHub.com.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a GitHub integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your GitHub data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for GitHub in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
GitHub can be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
User login cannot be changed after creation
GitHub usernames must be unique and follow GitHub naming rules (39 characters max, alphanumeric plus hyphens)
Email addresses must be unique across the GitHub instance
The following attributes can be synchronized:
Both adding and removing memberships are supported. Organization and team memberships are automatically removed during deprovisioning.
Add and remove organization memberships with member role
Add and remove team memberships with member role
Synchronize access assignments based on external identity changes
When a user is deprovisioned:
User account is suspended in GitHub Enterprise Server
All organization and team memberships are removed automatically
Commit history and attribution are preserved for audit and compliance
Create GitHub accounts and assign appropriate access for new developers:
Identity Sync: Create user account with basic profile information
Organization Access: Add user to primary GitHub organization
Team Assignment: Assign to development teams based on department
Update GitHub access when employees change departments or roles:
Relationship Updates: Remove existing team memberships
New Access: Add memberships for new role requirements
Audit Trail: Track all membership changes for compliance
Securely remove access while preserving development history:
Account Suspension: Suspend GitHub account to prevent access
Membership Removal: Remove all organization and team memberships
History Preservation: Maintain commit attribution and repository history
Configuring the Snowflake integration for Veza Lifecycle Management.
# Google Workspace User Attributes
email: {first_name}.{last_name}@company.com
first_name: {first_name}
last_name: {last_name}https://www.googleapis.com/auth/admin.directory.rolemanagement - Required for admin role management
https://www.googleapis.com/auth/apps.groups.settings - Required for detailed group settings management
https://www.googleapis.com/auth/cloud-platform - Required for Cloud Identity API and broader Google Cloud access
Add to: "Sales Team" group
Unique identifier
first_name
Yes
String
Given name
last_name
Yes
String
Family name
email_addresses
No
Array
Multiple email addresses as a list
Additional email formats
location_areas
No
Array
Location information as a list
organization_names
No
Array
Organization information as a list
Organization permissions - Members (Write) - Required for managing organization memberships
Organization permissions - Administration (Write) - Required for administrative operations
Repository permissions - Administration (Write) - Required for managing team memberships
emails
Yes
Array
List of email addresses
Primary email required
active
No
Boolean
User account status
true=active, false=suspended
public_email
No
String
Public email for profile
Must be in emails list
display_name
No
String
User's display name
Shown on GitHub profile
is_site_admin
No
Boolean
Site administrator privileges
GitHub Enterprise only
User receives appropriate error messages when attempting to access GitHub
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as organization and team memberships for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities by suspending accounts
✅
SOURCE_OF_IDENTITY
GitHub can act as a source system for identity lifecycle policies
❌
login
Yes
String
GitHub username
Unique identifier, immutable
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities
✅
SOURCE_OF_IDENTITY
Snowflake can act as a target system for identity lifecycle policies from other sources
✅
This document includes steps to enable the Snowflake integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration and USERADMIN role or equivalent privileges in Snowflake.
Ensure you have an existing Snowflake integration in Veza or add a new one for use with Lifecycle Management.
Verify your Snowflake integration has completed at least one successful extraction
The Snowflake integration will need the additional required privileges:
CREATE USER privilege on the account for user provisioning
GRANT ROLE privilege for role assignments
Important: The Snowflake user account used for Lifecycle Management operations should have USERADMIN role or higher privileges to ensure proper user and role management capabilities.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a Snowflake integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Snowflake data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Snowflake in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Snowflake can be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management Actions:
Primary action for user management (creating or updating users):
User names must be unique and follow Snowflake identifier naming conventions
Login names are used for authentication and must be unique
Passwords are automatically generated and set to require change on first login
Users are created with appropriate default settings for the Snowflake environment
The following attributes can be synchronized:
Role assignment management for users:
Add and remove role assignments for users
Synchronize role memberships from source systems
Support for direct role grants to users
Roles must exist in Snowflake before assignment
Within Snowflake, roles can be associated with:
Database and schema access permissions
Table and view privileges
Warehouse usage rights
Administrative privileges for account management
When a user is deprovisioned:
User account is disabled (set DISABLED = TRUE)
Role assignments are removed to revoke access
User attributes are preserved for audit purposes
Account can be reactivated if needed for compliance requirements
Automated provisioning when a new employee joins:
Create User Account: Sync identity attributes from HR system to create Snowflake user with name and login details
Assign Department Role: Grant role based on department attribute (e.g., SALES_ANALYST, DATA_ENGINEER)
Set Default Role: Configure default role for the user's session
Add Email and Comments: Populate user profile with contact information and descriptive notes
Managing access when employees change roles:
Update User Attributes: Sync changed attributes like email or comments
Remove Old Roles: Revoke previous role assignments that are no longer appropriate
Grant New Roles: Assign roles appropriate for the new position
Update Default Role: Change the user's default role for new sessions
Secure access removal when employees leave:
Disable Account: Set user account to disabled status
Revoke All Roles: Remove all role assignments to eliminate data access
Preserve Audit Trail: Maintain user record and history for compliance
Optional Cleanup: Remove user completely with DROP USER if no audit trail is needed
Configuring the Oracle Database integration for Veza Lifecycle Management
The Veza integration for Oracle DB enables automated user provisioning, access management, and deprovisioning capabilities. This integration allows you to synchronize identity information, manage group memberships, and automate the user lifecycle from onboarding to offboarding.
OWNERSHIP privilege on target roles for role managementAccess to a warehouse for executing queries during lifecycle operations
Unique identifier, immutable
login_name
No
String
Login identifier for authentication
Defaults to name if not provided
No
String
User's email address
Must be valid email format
comment
No
String
User description or notes
default_role
No
String
Default role for user sessions
Role must exist in Snowflake
password
No
String
User password
Auto-generated if not provided
disabled
No
Boolean
User account status
true = disabled, false = active
Role assignment and removal for access management
User account deletion for offboarding
Attribute synchronization for user profiles
Use this integration with Veza Lifecycle Management to:
Onboard users: Automatically create Splunk Enterprise accounts with initial role assignments
Manage access: Add or remove role memberships based on access policies
Offboard users: Delete accounts when users leave the organization
Update profiles: Synchronize user attributes like email and display name
Splunk Enterprise supports the following Lifecycle Management actions:
Action Type
Description
Supported Operations
Sync Identities
Create or update user accounts
Create, Update
Manage Relationships
Assign or remove role memberships
Add, Remove
Delete Identity
Permanently delete user accounts
Delete
Note: Splunk Enterprise does not support the Deprovision Identity action for disabling or locking user accounts. The Splunk API only supports permanent deletion via the Delete Identity action. To offboard users while maintaining audit records, use the Delete Identity action, which preserves activity logs even after account deletion.
Refer to the Lifecycle Management Overview for more information about creating policy-based provisioning workflows with Veza.
Before enabling Lifecycle Management for Splunk Enterprise, you will need:
An Existing Integration: Add a Splunk Enterprise integration and complete at least one successful extraction. See Splunk Enterprise integration.
Sufficient Permissions for Lifecycle Management: The Veza service account needs write capabilities beyond read-only access:
Capability
Required For
edit_user
SYNC_IDENTITIES, DELETE_IDENTITY
edit_roles_grantable or edit_roles
MANAGE_RELATIONSHIPS
The edit_user capability grants permission to create, modify, and delete any user account in Splunk Enterprise. Ensure this service account is properly secured and monitored.
To enable the Splunk Enterprise integration for Lifecycle Management:
In Veza, navigate to Integrations
Locate your Splunk Enterprise integration
Open the integration details
Enable Usage for Lifecycle Management
Verify the integration appears in Lifecycle Management > Integrations
See Managing Integrations for more information on configuring integrations for Lifecycle Management.
Creates new user accounts or updates existing user attributes in Splunk Enterprise.
Capabilities:
Create New Users: Yes
Update Existing Users: Yes
Entity Type: Splunk Enterprise User
Attribute
Type
Description
Example
name
String
Username (unique identifier, lowercase alphanumeric recommended)
jsmith
password
String
User password (required for create operations)
SecurePass123!
Attribute
Type
Description
Default
realname
String
User's display name or full name
Uses name if not provided
When creating a new user:
The name attribute becomes the unique username (must be unique within the Splunk Enterprise instance)
Both email and password are required for user creation. The password must meet your Splunk Enterprise deployment's password complexity requirements, which are configured by your Splunk administrator (e.g., minimum length, required character types).
If realname is not provided, it defaults to the name value
New users are automatically assigned the default user role (Splunk requires at least one role). You can use MANAGE_RELATIONSHIPS to grant additional role assignments
When updating an existing user:
Only the attributes specified in the update request are modified
Other attributes remain unchanged
The name attribute is used to identify the user, but cannot be changed
Password updates are supported, but require providing the new password value
Assigns or removes role memberships for Splunk Enterprise users.
Supported Relationship Types:
Relationship
Description
User → Role
Assign or remove a role for a user.
Splunk Enterprise implements a role relationship manager that:
Adds roles to users by updating the user's role list
Removes roles from users by updating the user's role list
Validates that the target role exists before assignment
Preserves all other assigned roles when adding or removing a single role
Only existing roles can be assigned. Splunk Enterprise groups (LDAP and SAML) are read-only and managed by external identity providers. Lifecycle Management cannot create or modify groups or create new roles.
When Adding a Role:
Veza retrieves the user's current role assignments
Checks if the role is already assigned (skips if already assigned)
Adds the new role to the user's role list
Updates the user with the complete role list
When Removing a Role:
Veza retrieves the user's current role assignments
Checks if the role is currently assigned (skips if not assigned)
Removes the target role from the user's role list
Updates the user with the remaining roles
Notes:
Users must have at least one role in Splunk Enterprise
Removing a user's last role assignment will fail
Role assignments are direct. A role may contain inherited roles depending on Splunk's role inheritance configuration.
Built-in roles (e.g., admin, user, power) can be assigned and removed
Custom roles created in Splunk Enterprise are also supported
Permanently deletes user accounts from Splunk Enterprise. Note that Splunk Enterprise does not have a native "disabled" or "locked" state for accounts (except lock-out).
Delete Method: The account and all associated data are permanently removed from Splunk Enterprise.
Attribute
Type
Description
name
String
Username of the account to delete
When deleting a user:
The user account is permanently removed
All role assignments are removed as part of the deletion
User-owned objects (saved searches, dashboards, etc.) may be affected based on Splunk configuration
The username can be reused for a new user after deletion
User deletion is permanent and cannot be undone through the API. While Splunk administrators can view audit logs to access deleted user records, consider removing role assignments (using MANAGE_RELATIONSHIPS) for temporary access revocations. Built-in system accounts (e.g., admin) cannot be deleted.
Create User Account (SYNC_IDENTITIES): Provide a name, email, password, and optionally realname. The user is created with the default user role.
Assign Roles (MANAGE_RELATIONSHIPS): Add role assignments based on job function.
Add Role (MANAGE_RELATIONSHIPS): Add a role assignment to the user
Remove Role (MANAGE_RELATIONSHIPS): Remove role assignment from the user
Revoke Access (Reversible): Remove all elevated roles via MANAGE_RELATIONSHIPS, leaving only the base user role.
Delete Account (Permanent): Use DELETE_IDENTITY to remove a user account permanently.
Use SYNC_IDENTITIES to update a user's email, realname, or password. Provide the name to identify the user; only the specified attributes are updated.
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships for identities
✅
DEPROVISION_IDENTITY
Safely removes or suspends access for identities
✅
DELETE_IDENTITY
Deletes the identity name, specifically the unique identifier associated with it.
✅
CREATE_ENTITLEMENT
Creates entitlements such as groups or roles
❌
SOURCE_OF_IDENTITY
This document outlines the steps to enable Oracle DB integration for use in Lifecycle Management, including supported actions and relevant notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration.
Ensure you have an existing Oracle Database integration in Veza or add a new one for use with Lifecycle Management.
Verify your Oracle DB integration has completed at least one successful extraction.
Database administrator privileges in Oracle DB (ability to create common users and grant privileges)
For multi-tenant configurations: access to CDB$ROOT container
Supported Oracle Database versions: 19c, 21c, or 23ai
Configuration Steps
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an Oracle DB integration
Check the box, Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Oracle DB data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Oracle DB in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Oracle DB can serve as a source for identity information in Lifecycle Management Policies. User identity details are synchronized from Oracle DB, with changes propagated to connected systems.
Oracle DB can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following Lifecycle Management Actions:
The following attributes can be synchronized:
username
Yes
String
User name Identifier
Must be unique, follow Oracle identifier naming rules
password
No
String
User password
Auto-generated if not provided, requires change on first login
Entity Type: OracleDB User
Create Allowed: Yes
Method: SQL CREATE USER / ALTER USER
Entity Types: OracleDB Role
Assignee Types: OracleDB User
Supports Remove: Yes
Method: SQL GRANT ROLE / REVOKE ROLE
Entity Type: OracleDB User
Method: DISABLED (account lock via ALTER USER ... ACCOUNT LOCK)
Removes Relationships: Yes
Entity Type: OracleDB User
Method: Permanent deletion via DROP USER
Create an Oracle DB user account with the Sync Identities action
Assign default role based on department with Manage Relationships
Set password (requires change on first login)
Configure profiles and tablespaces
Update user attributes (profile, tablespaces) with Sync Identities
Remove old role assignments with Manage Relationships
Grant new roles appropriate for the new position
Lock user account with Deprovision Identity (ACCOUNT LOCK)
Remove all role assignments
Preserve the user record for audit purposes
Optional: Delete user permanently with Delete Identity (DROP USER)
CustomHRISEmployee
CustomHRISEmployee
Supports email write-back
CustomHRISEmployee
AzureADUser
GoogleWorkspaceUser
OktaUser
OAA.Oracle HCM.HRISEmployee
Supports email write-back
ServiceNowUser
CustomHRISEmployee
WorkdayWorker
Supports email write-back
ActiveDirectoryUser
CustomHRISEmployee
CustomHRISEmployee
CustomIDPUser
✅
✅
✅
Reset Password, Create Entitlements, Delete Identity
ActiveDirectoryGroup
-
Configuring PostgreSQL Integration for Veza Lifecycle Management
The Veza integration for PostgreSQL enables automated user provisioning, access management, and deprovisioning capabilities. This integration allows you to synchronize identity information, manage group memberships, and automate the user lifecycle from onboarding to offboarding.
This document outlines the steps to enable PostgreSQL integration for use in Lifecycle Management, including supported actions and relevant notes. See for more details.
You will need administrative access in Veza to configure the integration and grant API scopes in PostgreSQL.
Ensure you have an existing PostgreSQL integration in Veza or add a new one for use with Lifecycle Management.
Verify your PostgreSQL integration has completed at least one successful extraction.
Configuration Steps
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a PostgreSQL integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your PostgreSQL data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for PostgreSQL in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
PostgreSQL can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from PostgreSQL, with changes propagated to connected systems.
PostgreSQL can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following Lifecycle Management :
Primary action for user management (creating or updating users):
Entity Types: PostgreSQL User
Create Allowed: Yes (New user identities can be created if not found)
SQL Command: CREATE ROLE {username} WITH LOGIN PASSWORD 'password' [attributes]
Note: In PostgreSQL's architecture, users are roles with the LOGIN privilege. When Veza creates a user, it uses CREATE ROLE with the LOGIN attribute. This is functionally identical to PostgreSQL's CREATE USER command, which is simply an alias for CREATE ROLE ... WITH LOGIN.
The following attributes can be synchronized:
Controls relationships between users and PostgreSQL groups:
Supported Relationship Types:
PostgreSQL Group: Manages group membership for users
Assignee Types: PostgreSQL User
Technical details:
Adding a user to a group: GRANT {group} TO {user}
Removing a user from a group: REVOKE {group} FROM {user}
Group memberships use PostgreSQL's role inheritance system, where users inherit permissions from their assigned groups
Disables a user's ability to authenticate to PostgreSQL while preserving the role and its attributes:
Entity Type: PostgreSQL User
Action: Revokes the LOGIN privilege (equivalent to ALTER ROLE {username} WITH NOLOGIN)
Removes All Group Memberships: Yes (user is removed from all PostgreSQL groups)
Use case: Temporary offboarding or leave of absence where you may need to restore access later.
Security note: A deprovisioned superuser cannot log in but retains SUPERUSER status. If the role is re-enabled without updating attributes, it will have full superuser privileges. Consider using a Sync Identities action to revoke SUPERUSER before deprovisioning if this is a concern.
Permanently removes a user role from PostgreSQL:
Entity Type: PostgreSQL User
Action: Drops the role from the database (equivalent to DROP ROLE {username})
Impact: Complete and irreversible removal of the role
Important limitations:
Will fail if the user owns database objects: PostgreSQL prevents dropping roles that own schemas, tables, functions, or other database objects. PostgreSQL will return an error: role "username" cannot be dropped because some objects depend on it
Will fail if the user has granted permissions: If the role has granted permissions to other roles or is referenced in default privileges, the drop will fail
Will fail if referenced in policies: Row-level security policies or other database policies that reference the role must be removed first
Note: Unlike some database systems, PostgreSQL allows dropping roles with active connections, but the operation will still fail if any of the above dependencies exist.
Recommended workflow:
Use Deprovision Identity first to revoke LOGIN and remove group memberships
Verify the user has no owned objects, granted permissions, or policy references
Use Delete Identity only when permanent removal is required
Alternative for users with dependencies: PostgreSQL administrators can manually run REASSIGN OWNED BY {username} TO {new_owner} followed by DROP OWNED BY {username} before triggering deletion through Veza, or handle the deletion entirely through PostgreSQL.
Configuring the Active Directory integration for Veza Lifecycle Management
Configuring the ServiceNow integration for Veza Lifecycle Management
Oracle DB provides worker data as input for identity lifecycle policies
❌
account_status
No
String
Account status
Values: OPEN, LOCKED, EXPIRED, etc.
profile
No
String
User profile
Profile must exist in the Oracle DB
default_tablespace
No
String
Default tablespace
Tablespace must exist
temporary_tablespace
No
String
Temporary tablespace.
Typically TEMP
authentication_type
No
String
Authentication method
PASSWORD, EXTERNAL, GLOBAL, etc.
✅
✅
✅
Delete Identity
AtlassianCloudAdminGroup
-
✅
✅
✅
Create Entitlement
AwsSsoGroup
-
✅
✅
✅
Create & Manage Email, Create Entitlement
AzureADGroup, AzureADRole, ExchangeOnlineDistributionGroup, AzureADLicense
Email management includes mailbox configuration (size limits, quotas, auditing) and client access settings (OWA, ActiveSync, MAPI, POP, IMAP)
✅
✅
✅
Delete Identity
ApplicationGroup, ApplicationRole
-
❌
❌
❌
Create Email
-
-
✅
✅
✅
-
GithubOrganization, GithubTeam
-
✅
✅
✅
-
GoogleWorkspaceGroup
-
✅
✅
✅
Delete Identity
MySQLRoleInstance
-
✅
✅
✅
Reset Password, Create Entitlement
OktaGroup
Supports two deprovision types: SUSPENDED (temporary) and DISABLED (permanent deactivation)
✅
✅
✅
Delete Identity
OracleDBRole
-
✅
✅
✅
Delete Identity
OracleRole
-
❌
✅
❌
-
-
-
✅
✅
❌
Delete Identity
PagerDutyTeam
Platform does not support user deactivation; use Delete Identity instead
✅
✅
✅
Delete Identity
PostgreSQLGroup
-
✅
✅
✅
-
SalesforceGroup, SalesforcePermissionSet, SalesforcePermissionSetGroup, SalesforceProfile, SalesforceUserRole
-
SAP ECC
✅
✅
✅
-
SapEccRole
-
❌
✅
✅
-
-
-
❌
❌
❌
Custom Action
-
-
✅
✅
✅
-
SnowflakeRole
-
✅
✅
❌
Delete Identity
SplunkEnterpriseRole
Platform does not support user deactivation; use Delete Identity instead
✅
✅
❌
-
WorkdaySecurityGroup
-
Veza
✅
✅
✅
-
VezaRoleBinding, VezaAccessProfile, VezaGroup
-
Note: SUPERUSER is required because Lifecycle Management may need to create or modify roles with SUPERUSER, BYPASSRLS, or other elevated privileges. Without SUPERUSER, the service account cannot manage roles with privileges equal to or greater than its own.
Boolean
Grants SUPERUSER privilege. Superusers bypass all permission checks and have full control over the database. Use with extreme caution.
can_create_db
No
Boolean
Grants CREATEDB privilege, allowing the role to create new databases.
can_create_role
No
Boolean
Grants CREATEROLE privilege, allowing the role to create, alter, and drop other roles. Cannot modify superusers unless the role is also a superuser.
can_initiate_streaming_replication
No
Boolean
Grants REPLICATION privilege. Allows the role to connect in replication mode and access Write-Ahead Log (WAL) streams. Typically used for replication standby servers.
can_by_pass_all_row_level_security
No
Boolean
Grants BYPASSRLS privilege. Allows the role to bypass Row-Level Security (RLS) policies on all tables. Use when the role needs unrestricted access to data regardless of RLS policies.
Preserves:
The role itself (can be re-enabled later)
All role attributes (SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS)
Ownership of database objects (tables, schemas, etc.)
Granted permissions on database resources
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones.
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships for identities.
✅
DEPROVISION_IDENTITY
Safely removes or suspends access for identities.
✅
DELETE_IDENTITY
Deletes the identity name, specifically the unique identifier associated with it.
✅
name
Yes
String
The role name (unique identifier). Must follow PostgreSQL naming rules: start with a letter or underscore, contain only alphanumeric characters and underscores, maximum 63 bytes.
is_super_user
No
ALTER ROLE veza_service WITH SUPERUSER CREATEROLE;SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments for identities
✅
DEPROVISION_IDENTITY
Safely disables access for identities while preserving attributes for audit
✅
CREATE_ENTITLEMENT
Creates entitlements such as Active Directory groups
✅
RESET_PASSWORD
Allows password reset operations for Active Directory users
✅
DELETE_IDENTITY
Permanently deletes the user identity from Active Directory
✅
SOURCE_OF_IDENTITY
Active Directory can act as a source system for identity lifecycle policies
✅
This document includes steps to enable the Active Directory integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration.
Ensure you have an existing Active Directory integration in Veza or add a new one for use with Lifecycle Management.
Verify your Active Directory integration has completed at least one successful extraction.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an Active Directory integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Active Directory data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Active Directory in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Create a dedicated AD user with the minimum required permissions:
Using Active Directory Users and Computers:
Open Active Directory Users and Computers
Navigate to the target Organizational Unit
Right-click > New > User
Complete the new user details form
Recommended name: "Veza AD Lifecycle Manager"
Set a strong password
Uncheck "User must change password at next logon"
Using PowerShell:
Grant the service account permissions to manage users in the target OUs:
Using Active Directory Users and Computers:
Navigate to the target Organizational Unit
Right-click > Delegate Control
Click Add and enter the service account name
Select these delegated tasks:
Create, delete, and manage user accounts
Reset user passwords and force password change
Read all user information
Using PowerShell:
Navigate to Configurations > Integrations
Either:
Create a new Active Directory integration
Edit an existing Active Directory integration
Enable Lifecycle Management:
Check Enable Lifecycle Management
Enter the Lifecycle Management Username (service account created above)
Save the configuration
The AD user created for lifecycle management can be the same as the primary AD user created for extraction, provided that the user has all the required permissions listed above.
Active Directory can serve as a source for identity information in Lifecycle Management Policies. User identity details are synchronized from Active Directory, with changes propagated to connected systems.
Active Directory can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management Actions:
Synchronizes identity attributes between systems, with options to:
Create new identities if they don't exist
Update attributes of existing identities
Enable continuous sync to keep attributes aligned with the source of truth
Unique Identifiers
Active Directory uses composite unique identifiers to locate users. Only one unique identifier can be specified per action:
account_name (sAMAccountName) - Default unique identifier
distinguished_name - Full LDAP path (e.g., CN=John Doe,OU=Users,DC=company,DC=com)
user_principal_name - Login format (e.g., [email protected])
The following attributes can be synchronized:
Controlling account state with user_account_control
The user_account_control attribute controls the account state during identity synchronization, enabling scenarios like creating pre-staged disabled accounts or setting custom account flags.
Supported flags:
NORMAL_ACCOUNT
Standard user account (required for most scenarios)
ACCOUNTDISABLE
Disables the account
DONT_EXPIRE_PASSWORD
Password never expires
PASSWD_NOTREQD
No password required
PASSWD_CANT_CHANGE
User cannot change password
SMARTCARD_REQUIRED
Smart card required for login
Combine multiple flags with commas. For example, NORMAL_ACCOUNT,ACCOUNTDISABLE creates a disabled account (equivalent to integer value 514).
Input format requirements:
Use flag names only: Enter the exact flag names shown above (e.g., NORMAL_ACCOUNT). Integer values like 512 or 514 are not supported and will be ignored.
Invalid flags are silently ignored: Unrecognized flag names are skipped without warning. Always verify flag names match exactly (case-insensitive).
Common combinations:
NORMAL_ACCOUNT
512
Standard user provisioning (default)
NORMAL_ACCOUNT,ACCOUNTDISABLE
514
Pre-staging accounts before start date
NORMAL_ACCOUNT,DONT_EXPIRE_PASSWORD
66048
Service accounts
NORMAL_ACCOUNT,ACCOUNTDISABLE,DONT_EXPIRE_PASSWORD
66050
If user_account_control is not specified in your transformer, the default value (512) is used and accounts are created in an enabled state.
Example use cases:
Pre-staged accounts: Create accounts in a disabled state before an employee's start date, then enable them via a separate workflow when the start date arrives
Approval workflows: Create disabled accounts that require manager approval before activation
Service accounts: Set specific flags like "password never expires" for service accounts
Graph visibility: Disabled users (accounts with ACCOUNTDISABLE flag set, such as value 514) are filtered out during Active Directory extraction and will not appear in the Veza graph. This is expected behavior—once the account is enabled, it will appear in the graph after the next extraction.
For a complete list of userAccountControl flag values and their meanings, see Microsoft documentation: UserAccountControl flags.
Controls relationships between users and Active Directory groups:
Entity Types: Active Directory Groups
Assignee Types: Active Directory Users
Supports Removing Relationships: Yes
Both adding and removing group memberships are supported. Group memberships can be managed individually or removed in bulk during deprovisioning.
When a user is deprovisioned in Active Directory:
Entity Type: Active Directory User
Method: Account Disabled (sets userAccountControl to 514)
Remove All Relationships: Yes (optional - group memberships can be removed)
What is preserved:
User account structure (not deleted)
All user attributes (name, email, title, etc.)
Audit history and account information
Account can be reactivated by re-enabling
What changes:
Account is disabled (login prevented)
Group memberships are removed (optional, based on workflow configuration)
User cannot authenticate or access AD resources
The following unique identifiers can be used to locate the user:
Creates new Active Directory groups:
Entity Type: Active Directory Group
Required Attributes: name
Optional Attributes: description, group_type, is_security_group, member_of, account_name, organizational_unit_dn
Resets a user's password in Active Directory:
Entity Type: Active Directory User
Idempotent: No (generates a new password with each execution)
Password Options:
Configurable password complexity (length, character types, excluded characters)
Option to require password change on next login
Passwords must comply with Active Directory domain password policy
The Reset Password action is non-idempotent. Each execution generates a new password, even if the action is run multiple times.
Password Complexity Options:
Length: Configurable minimum password length
Character Types: Uppercase, lowercase, numbers, special characters
Disallowed Characters: Specify characters to exclude from generated passwords
Require Change: Force user to change password on next login
The following unique identifiers can be used to locate the user:
Permanently removes a user from Active Directory:
Entity Type: Active Directory User
Method: Permanent deletion (DROP USER equivalent)
Warning: This action cannot be undone
Delete Identity permanently removes the user account from Active Directory. Use Deprovision Identity instead if you need to preserve the account for audit or potential reactivation.
The following unique identifiers can be used to locate the user:
Automate user creation and group assignment when a new employee joins:
Create a Lifecycle Management policy with your HR system as the source of identity
Configure a workflow triggered when a new identity is detected
Add a Sync Identities action to create the AD user:
Map HR attributes to AD attributes (name, email, department, title, manager)
Set initial password with "require change on next login"
Add a Manage Relationships action to assign initial group memberships based on role/department
Update access when an employee changes roles:
Create a policy with your HR system as the source of identity
Configure a workflow triggered when attributes change (department, title, or manager)
Add a Sync Identities action to update user attributes
Add a Manage Relationships action to:
Remove old role-based group memberships
Add new role-based group memberships
Disable access when an employee leaves:
Create a policy with your HR system as the source of identity
Configure a workflow triggered when termination date is set or employee status changes
Add a Deprovision Identity action:
Account will be disabled (not deleted)
Group memberships will be removed
Attributes preserved for audit
Optionally schedule a Delete Identity action after retention period (e.g., 90 days)
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
❌
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments
❌
DEPROVISION_IDENTITY
Safely removes or disables access for identities
❌
CREATE_ENTITLEMENT
Creates entitlements such as groups or roles
❌
CUSTOM_ACTION
Inserts records into any ServiceNow table
✅
SOURCE_OF_IDENTITY
ServiceNow can act as a source system for identity lifecycle policies
✅
This document includes steps to enable the ServiceNow integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration.
Ensure you have an existing ServiceNow integration in Veza or add a new one for use with Lifecycle Management.
Verify your ServiceNow integration has completed at least one successful extraction.
ServiceNow release Tokyo or newer is required.
The existing ServiceNow integration credentials (admin and snc_read_only roles) are sufficient for Lifecycle Management. Custom Actions use the same Table API as the standard integration.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a ServiceNow integration
Check the box to Enable usage for Lifecycle Management
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
ServiceNow can serve as a source for identity information in Lifecycle Management Policies. User identity details, group memberships, and role assignments are synchronized from ServiceNow with changes propagated to connected systems.
ServiceNow can also be a target for Custom Actions that insert records into ServiceNow tables as part of automated workflows.
The integration supports the following lifecycle management Actions:
ServiceNow provides identity information for lifecycle policies using the ServiceNowUser entity type. The following information is available:
User Identities: Users with their email addresses, employee numbers, and profile attributes (entity type: ServiceNowUser)
Group Memberships: ServiceNow groups that users belong to are tracked as relationships and can be referenced in transformer policies
Role Assignments: ServiceNow roles assigned to users (both direct and inherited) are tracked as relationships and can be referenced in transformer policies
When used as a source of identity, ServiceNow user attributes can be mapped to target systems through attribute transformers and lifecycle management policies.
Custom Actions enable Veza to insert records into any ServiceNow table. This is useful for:
Creating incident tickets for access changes
Logging audit records for compliance
Triggering ServiceNow workflows via table insertions
Recording access request approvals or denials
Custom Actions are non-idempotent. Each execution creates a new record in the specified ServiceNow table. Running the same action multiple times will create duplicate records.
Configuration
When configuring a Custom Action for ServiceNow, specify the target table and any additional fields:
table
Yes
String
The ServiceNow table name to insert records into
(additional)
No
String
Any additional fields to set on the new record
Attribute names can only contain lowercase letters, numbers, and underscores (a-z, 0-9, _). This matches ServiceNow's field naming conventions.
Example: Creating an Incident Record
To create an incident ticket when access is revoked:
Create a policy with your source of identity (e.g., Workday, Okta)
Configure a workflow with a Custom Action targeting ServiceNow
Set the action attributes:
Attribute values use Transformer syntax. Use {attribute_name} to reference source identity attributes (e.g., {email}, {name}, {employee_number}). See the Transformer Reference for available functions.
The Custom Action will POST to the ServiceNow Table API (/api/now/table/incident) and create a new incident record.
Example: Audit Trail Records
To maintain an audit trail of lifecycle management actions:
Create a custom table in ServiceNow for audit records (e.g., u_veza_audit_log)
Configure a Custom Action with:
table
u_veza_audit_log
When ServiceNow serves as a source of identity, the following user attributes are available for mapping in transformers:
If you have configured Custom Properties for your ServiceNow integration, those additional user attributes are also available for use in lifecycle management workflows.
No User Provisioning: ServiceNow Lifecycle Management does not support creating, updating, or disabling user accounts directly. Use Custom Actions to trigger ServiceNow workflows that handle user provisioning.
No Group/Role Management: Direct management of ServiceNow group memberships or role assignments is not supported. Use Custom Actions to create requests that trigger ServiceNow's native provisioning workflows.
Non-Idempotent Actions: Custom Actions always create new records. Design workflows accordingly to avoid duplicate entries.
Lifecycle Management Policies
Actions Reference
Configuring the PagerDuty integration for Veza Lifecycle Management
The Veza integration for PagerDuty enables automated user provisioning, team membership management, and user deletion capabilities. This integration allows you to synchronize identity information, manage team assignments, and automate the user lifecycle from onboarding to offboarding.
This document includes steps to enable the PagerDuty integration for use in Veza Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration.
Ensure you have an existing in Veza or add a new one for use with Veza Lifecycle Management.
Verify your PagerDuty integration has completed at least one successful extraction.
For testing and development, you can create a free PagerDuty developer account at . Developer accounts are limited to a maximum of 3 simultaneous users, but you can delete and recreate users as needed.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a PagerDuty integration
Ensure the following configuration is complete:
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
PagerDuty can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from PagerDuty, with changes propagated to connected systems.
PagerDuty does not support account deactivation or suspension. Users can only be fully deleted from the system. The DEPROVISION_IDENTITY action is not available for this integration. Use DELETE_IDENTITY instead when removing user access.
PagerDuty can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
Entity Types: OAA.PagerDuty.User
Create Allowed: Yes - New user identities can be created if not found
The following attributes can be synchronized:
Identity Model: PagerDuty users are uniquely identified by their email address. The email attribute is used for all user lookup and synchronization operations.
Permanently removes a user from PagerDuty:
Entity Type: OAA.PagerDuty.User
Remove All Relationships: Yes - All team memberships are automatically removed
Deletion Method: Permanent deletion via PagerDuty API
Permanent Action: User deletion in PagerDuty is permanent and cannot be undone. All user data, including incident history and on-call schedules, will be affected. PagerDuty does not support user suspension or deactivation - deletion is the only method to remove user access.
To provision a new user in PagerDuty and assign them to relevant teams:
Create a policy with your HRIS or identity source (e.g., Workday, Okta)
Configure a workflow for user creation with condition: {job_role} == "Engineer"
Add a Sync Identities action:
To remove a departing user from PagerDuty:
Create a policy with your HRIS or identity source
Configure a workflow for user termination with condition: {employee_status} == "Terminated"
Add a Delete Identity action:
Before deleting a user, ensure they are not assigned to any active on-call schedules or escalation policies that could impact incident response.
PagerDuty enforces API rate limits on all operations. The Veza integration automatically handles rate limiting by:
Monitoring the X-RateLimit-Remaining and X-RateLimit-RetryAfter response headers
Automatically retrying requests after the rate limit reset time
Using exponential backoff for failed requests
If you encounter errors during high-volume operations, consider:
Scheduling bulk provisioning operations during off-peak hours
Batching user creation across multiple workflow executions
Contacting PagerDuty support to discuss rate limit increases for your account
Free and developer PagerDuty accounts have user limits:
Developer accounts: Maximum of 3 simultaneous users
Free tier: Check your PagerDuty plan for specific limits
For production use of Lifecycle Management with PagerDuty, verify that your PagerDuty subscription supports the number of users you plan to manage.
When working with PagerDuty teams in lifecycle management:
Teams are referenced by their PagerDuty team ID (e.g., PCALT99)
Team IDs can be found in the PagerDuty UI under People > Teams or via the Veza entity browser
In Veza, team entity IDs follow the format: custom_provider:application:[datasource_id]:pagerduty:team:[team_id]
New-ADUser -Name "Veza AD Lifecycle Manager" `
-Path "OU=<your_OU>,DC=<domain>,DC=<tld>" `
-GivenName "Veza" `
-Surname "AD Lifecycle Manager" `
-SamAccountName "veza-ad-lcm" `
-AccountPassword (ConvertTo-SecureString -AsPlainText "<password>" -Force) `
-ChangePasswordAtLogon $False `
-DisplayName "Veza AD Lifecycle Manager" `
-Enabled $TrueImport-Module ActiveDirectory
$OrganizationalUnit = "OU=<your_OU>,DC=<domain>,DC=<tld>"
$Users = [GUID]"bf967aba-0de6-11d0-a285-00aa003049e2"
Set-Location AD:
$User = Get-ADUser -Identity "veza-ad-lcm"
$UserSID = [System.Security.Principal.SecurityIdentifier] $User.SID
$Identity = [System.Security.Principal.IdentityReference] $UserSID
# Create permission for managing users
$RuleCreateDeleteUsers = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $Identity, "CreateChild, DeleteChild", "Allow", $Users, "All"
# Create permission for password resets
$ResetPassword = [GUID]"00299570-246d-11d0-a768-00aa006e0529"
$RuleResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($Identity,
"ExtendedRight", "Allow", $ResetPassword, "Descendents", $Users)
# Apply permissions
$ACL = Get-Acl -Path $OrganizationalUnit
$ACL.AddAccessRule($RuleCreateDeleteUsers)
$ACL.AddAccessRule($RuleResetPassword)
Set-Acl -Path $OrganizationalUnit -AclObject $ACLCan be used as unique identifier
distinguished_name
Yes
String
Full LDAP distinguished name path
Can be used as unique identifier
user_principal_name
Yes
String
User's principal name (login format)
Can be used as unique identifier
account_expires
No
Date/Time
Account expiration date and time
city
No
String
City
company
No
String
Company name
country_code
No
String
ISO 3166 Alpha-2 country code
country_or_region
No
String
Country or region name
department
No
String
Organizational department
description
No
String
User description
display_name
No
String
Display name
No
String
Email address
Can be used as unique identifier
given_name
No
String
First name
manager_id
No
String
Manager's sAMAccountName
office
No
String
Office location
physical_delivery_office_name
No
String
Physical office name
postal_code
No
String
Postal/ZIP code
primary_group_dn
No
String
Distinguished name of primary group
state_or_province_name
No
String
State or province
street_address
No
String
Street address
sur_name
No
String
Last name/surname
title
No
String
Job title
user_account_control
No
String List
Account control flags
Comma-separated flag names (e.g., NORMAL_ACCOUNT,ACCOUNTDISABLE). See Controlling Account State for details.
Pre-staged service accounts
String
Full LDAP distinguished name path
Can be used as unique identifier
user_principal_name
String
User's principal name (login format)
Can be used as unique identifier
String
Email address
Can be used as unique identifier
Maximum 64 characters
account_name
No
String
Group account name (sAMAccountName)
Maximum 256 characters, must be unique
description
No
String
Group description
group_type
No
String
Type of group
Values: Domain, System, Global, Universal, App Basic, App Query
is_security_group
No
Boolean
Whether this is a security group
member_of
No
String
Distinguished name of parent group(s)
organizational_unit_dn
No
String
Distinguished name of target OU
String
Full LDAP distinguished name path
Can be used as unique identifier
String
Email address
Can be used as unique identifier
user_principal_name
String
User's principal name (login format)
Can be used as unique identifier
String
Full LDAP distinguished name path
Can be used as unique identifier
user_principal_name
String
User's principal name (login format)
Can be used as unique identifier
String
Email address
Can be used as unique identifier
table
incident
short_description
Access revoked for {email}
description
User {name} ({employee_number}) access revoked
category
access_management
priority
3
u_user_email
{email}
u_employee_id
{employee_number}
u_user_source
{source}
u_action_source
Veza Lifecycle Management
employee_number
String
Employee identifier
source
String
Identity source (e.g., LDAP, manual)
is_active
Boolean
Whether the user account is active
is_locked
Boolean
Whether the user account is locked
mfa_active
Boolean
MFA enabled for the user
password_needs_reset
Boolean
Whether the user must reset their password
failed_attempts
Number
Number of failed login attempts
web_service_access_only
Boolean
API-only account (no UI access)
internal_integration_user
Boolean
Internal integration service account
identity_type
String
Identity classification (HUMAN or NONHUMAN)
created_at
Timestamp
Account creation date
last_login_at
Timestamp
Last login date
API Access Token: A PagerDuty API token with full read and write permissions (not read-only)
API URL: Your PagerDuty instance URL (e.g., https://yourcompany.pagerduty.com or use api.pagerduty.com for API-direct access)
Admin Email: The email address of a PagerDuty admin user (required for user creation and modification operations)
https://yourcompany.pagerduty.com)Token: A valid API access key with write permissions
Admin Email: The email address used for administrative operations
Check the box to Enable usage for Lifecycle Management
name
Yes
String
Full name of the user
role
No
String
PagerDuty role assigned to the user
Common values: user, admin, limited_user
job_title
No
String
Job title of the user
time_zone
No
String
Time zone for the user in tzinfo format (e.g., 'America/New_York')
Must be a valid IANA time zone string
description
No
String
Description or notes about the user
Requirements: The user must exist in PagerDuty (identified by email or user ID)
Target Integration: PagerDuty
Entity Type: OAA.PagerDuty.User
Create if Not Found: Enabled
Attribute mapping:
Target Integration: PagerDuty
Entity Type: OAA.PagerDuty.User
Identifier mapping: email: {work_email}
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
DELETE_IDENTITY
Permanently removes users from PagerDuty
✅
email
Yes
String
Email address of the user (used as unique identifier)
Must be unique across all PagerDuty users
email: {work_email}
name: {first_name} {last_name}
role: user
time_zone: {time_zone | DEFAULT_VALUE: "America/New_York"}
job_title: {job_title}SOURCE_OF_IDENTITY
Oracle HCM provides worker data as input for identity lifecycle policies
✅
EMAIL_WRITE_BACK
Writes email addresses from target systems back to Oracle HCM worker records
✅
SYNC_IDENTITIES
Synchronizes identity attributes to Oracle HCM (as target)
❌
CREATE_IDENTITY
Creates new user accounts or worker records
This document includes steps to enable the Oracle HCM integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration and appropriate access in Oracle HCM.
Ensure you have an existing Oracle HCM integration in Veza or add a new one for use with Lifecycle Management.
Verify your Oracle HCM integration has completed at least one successful extraction
The Oracle HCM service account requires specific permissions for different operations:
REST API Permissions (Read-only):
/hcmRestApi/resources/11.13.18.05/workers - View worker records
/hcmRestApi/resources/11.13.18.05/jobs - View job information
/hcmRestApi/resources/11.13.18.05/actionsLOV - View available actions
SCIM API Permissions:
/hcmRestApi/scim/Users - User management endpoint
GET: Read user by ID, person number, or username
PATCH: Update user email addresses only (write-back functionality)
BI Publisher Permissions:
Execute reports via the QueryDM interface
Access to custom report path (must start with /Custom and end with .xdo)
Retrieve CSV-formatted report output
Important: Oracle HCM integration requires specific report configurations and API access. Ensure your Oracle HCM user account has sufficient privileges to read worker data and update email addresses.
Technical Requirements:
Oracle HCM REST API version: 11.13.18.05
REST Framework version: 4
SCIM 2.0 support for user operations
HTTP Basic Authentication
Concurrent request limit: 8 (for optimal performance)
Configuration Parameters:
url: Oracle HCM instance URL (required)
username: Service account username (required)
password: Service account password (required)
report_path: BI Publisher report path starting with /Custom (required)
additional_columns: Comma-separated list of additional CSV columns to extract (optional)
identity_mapping: Custom identity mapping configuration (optional)
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an Oracle HCM integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Oracle HCM data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Oracle HCM in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Oracle HCM integration relies on BI Publisher reports to extract worker data. The report must be properly configured with specific requirements:
Must be an absolute path starting with /Custom
Must end with .xdo extension
Example: /Custom/HCM/WorkerDataReport.xdo
The BI Publisher report must output CSV data with these exact column headers:
Core Required Columns:
CORRELATION_ID - Unique worker identifier (required)
EMPLOYEE_ID - Employee number/ID (required)
FIRST_NAME - Worker's first name (required)
LAST_NAME - Worker's last name (required)
STATUS - Employment status (must be "ACTIVE" for active workers)
START_DATE - Employment start date in YYYY-MM-DD format
Additional Standard Columns:
NAME - Full name
COMPANY_NAME - Company name
PREFERRED_FIRST_NAME - Preferred first name
DISPLAY_NAME - Display name
CANONICAL_NAME - Canonical name
USER_NAME - Username
EMAIL - Primary email address
PERSONAL_EMAIL - Personal email
HOME_LOCATION - Home location
LOCATION - Work location
COST_CENTER - Cost center code
DEPARTMENT_NAME - Department name
MANAGER - Manager's correlation ID
ACTIVE - Active flag (Y/N)
TERM_DATE - Termination date in YYYY-MM-DD format
TITLE - Job title
EMPLOYEE_TYPE - Employment type (full time, part time, contractor)
Date Format: All dates must use YYYY-MM-DD format
Employment Status: Must be exactly "ACTIVE" for active workers (case-sensitive)
Boolean Values: Use "Y" or "N" for the ACTIVE column
Duplicate Records: System handles duplicates by keeping the most recent active record
Oracle HCM serves as a source for identity information in Lifecycle Management Policies. Based on the implementation configuration, Oracle HCM supports only two specific actions:
Oracle HCM provides authoritative worker information for identity lifecycle policies:
Data Flow: FROM Oracle HCM TO target systems (unidirectional)
Purpose: Serves as the authoritative source for worker identity data
Scope: Worker records from BI Publisher reports are made available to lifecycle policies
Usage: Target systems can query Oracle HCM worker data for provisioning decisions
Available Worker Attributes for Lifecycle Management:
Oracle HCM uses a multi-layer attribute system:
BI Publisher Report Fields: Over 20 fields available for reading worker data (see BI Publisher Report Configuration)
Lifecycle Management Attributes: Only 3 attributes are available for synchronization:
user_name
Yes
String
userName
Worker username
Primary identifier, required for all operations
No
String
Important: The SCIM API only supports these three attributes for write operations. All other worker data from BI Publisher reports is read-only.
Workers can be identified using multiple approaches:
Person Number (Preferred): Extracted from entity ID for most operations
Entity ID: Used for direct operations and testing scenarios
SCIM User ID: Used specifically for email write-back operations
Oracle HCM supports writing email addresses from target systems back to worker records:
Direction: Unidirectional - writes email addresses FROM provisioned target systems TO Oracle HCM worker records
Method: Uses SCIM PATCH operation to update worker email addresses
Worker Identification: Supports both entity ID-based and person number-based worker identification
Limitation: Oracle HCM SCIM API supports only one email address per worker record
Logic: Only updates if the new email address differs from the existing value
When an email address is created in a target system (such as Exchange or Google Workspace), the write-back action updates the corresponding Oracle HCM worker record with the new email address via the /hcmRestApi/scim/Users endpoint.
Oracle HCM can serve as the source of truth for new hire provisioning workflows:
Worker Added in Oracle HCM: New worker record is created with basic information
Identity Sync: Worker attributes are synchronized to target systems (Active Directory, Okta, etc.)
Email Creation: Corporate email account is created in the target email system
Email Write-Back: The newly created email address is written back to the Oracle HCM worker record
When worker information changes in Oracle HCM:
Attribute Changes: Worker attributes are updated in Oracle HCM (department, title, etc.)
Continuous Sync: Changes are automatically propagated to connected target systems
Consistency Maintenance: All systems maintain consistent worker information
For workers who need new email addresses:
Email Creation: Target email system creates a new email account
Write-Back Process: Oracle HCM worker record is updated with the new email address via SCIM API
Identity Sync: Updated email information is synchronized across all connected systems
Report Path Errors:
Ensure report path starts with /Custom and ends with .xdo
Verify the report exists and is accessible
Check BI Publisher permissions
Column Mapping Issues:
Verify all required column headers are present in CSV output
Check column name spelling (case-sensitive)
Ensure date columns use YYYY-MM-DD format
Authentication Failures:
Verify HTTP Basic Authentication credentials
Check user has access to required API endpoints
Confirm SCIM permissions for email write-back
Data Processing Problems:
STATUS column must contain "ACTIVE" for active workers
CORRELATION_ID must be unique for each worker
Handle duplicate records appropriately
Email Write-Back Issues:
Verify worker exists and is identifiable by person number or entity ID
Check SCIM endpoint permissions
Only one email address per worker is supported
Configuring the Workday integration for Veza Lifecycle Management
The Veza integration for Workday enables automated Lifecycle Management workflows using Workday as a source of truth for employee identity information. This integration supports identity synchronization, security group management, and bidirectional email updates.
This document includes steps to enable the Workday integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration and administrative access in Workday to configure security policies.
Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.
Verify your Workday integration has completed at least one successful extraction.
Worker data syncs to Veza follow the configured extraction interval (default: 1-hour minimum). See for scheduling details.
1. Create Business Process Security Policy
Log into Workday and search for Edit Business process security policy
Under Business Process Type, select Work Contact Change
Find "Initiating Action: Change Work Contact Information (REST Service)"
2. Activate Security Policy Changes
Search for Activate Pending Security Policy Changes
Review changes, add a comment, and click OK
Verify changes in Business Process Security Policy
3. Configure Security Group Permissions
Add these Domain Permissions to the security group:
4. Update API Client Configuration
Open Edit API Client
Add required scopes:
Staffing
5. Configure Workday Integration in Veza
Navigate to Configurations > Integrations
Either:
Create a new Workday integration
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Workday serves as a source for identity information in Lifecycle Management . Worker identity details are synchronized from Workday with changes propagated to connected systems.
Workday can also be a target for relationship management and email write-back actions, based on changes in lifecycle policies or workflows.
The integration supports the following lifecycle management :
Workday provides identity information for lifecycle policies using the WorkdayWorker entity type. Worker records serve as the authoritative source for employee identity information to trigger lifecycle management workflows.
When used as a source of identity, Workday worker attributes can be mapped to target systems through attribute transformers and lifecycle management policies.
Controls access to Workday security groups for Workday accounts. Both adding and removing group memberships are supported.
Entity Types: Workday Security Group
Assignee Types: Workday Account
Supports Relationship Removal: Yes
This action enables automated security group assignments for:
New employee onboarding
Role changes and transfers
Access removal during offboarding
Updates email addresses in Workday worker records to maintain consistency with other systems. This ensures Workday remains the single source of truth for employee email addresses.
Entity Type: Workday Worker
Purpose: Synchronizes email address changes from other systems back to Workday
The integration uses Workday's Work Contact Information Change business process to update email addresses. Each email update creates a new work contact change record that is submitted to Workday for processing.
The integration supports custom attributes defined in your Workday configuration. Custom properties can be configured in the and used in lifecycle management conditions and transformers.
The integration uses these API endpoints for email write-back:
For general metadata discovery, WQL queries access:
allWorkdayAccounts
allWorkers
securityGroups
domainSecurityPolicies
Workday Workers are the primary entity for identity information and source of truth
Bidirectional management of Account-Security Group relationships is supported
Email write-back operates on Worker entities, not Account entities
Configuring the MySQL integration for Veza Lifecycle Management
The Veza integration for MySQL enables automated user provisioning, access management, and deprovisioning capabilities. This integration allows you to synchronize identity information, manage role memberships, and automate the user lifecycle from onboarding to offboarding.
Note: Only email updates are performed; full user creation/deletion not used
Uses same BI Publisher infrastructure as Oracle Fusion Cloud integration.
❌
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments
❌
DEPROVISION_IDENTITY
Safely removes or disables access for identities
❌
CREATE_ENTITLEMENT
Creates entitlements such as groups or roles
❌
emails[0].value
Worker's email address
Can be updated via write-back, single email only
display_name
No
String
displayName
Worker's display name
May experience update delays
Work Contact Change Business Process Security Policy - For email write-back operations
Domain Permissions - View and Modify permissions for various Workday data domains (see Configure Security Group Permissions)
API Client Scopes - Additional scopes for Staffing, Contact Information, Organizations and Roles (see Update API Client Configuration)
Create a Segment-Based Security Group
Configure the security group:
Add the security group created for Veza integration
Add "Worker" scope to Access Rights
Verify the security group appears in Initiating Action Security groups
Click OK and Done to save changes
Business Process Administration
View and Modify
Security Administration
View and Modify
Workday accounts
View and Modify
Special OX Web Services
Get and Put
User-Based Security Group Administration
System
Tenant Non-Configurable
Organizations and Roles
Enable Lifecycle Management:
Check Enable Lifecycle Management
If using custom attributes, configure them in the Custom Properties section
last_name
String
Worker's last name
name
String
Worker's full name (node name in Veza graph)
employee_id
String
Employee identifier
business_title
String
Worker's business title
position
String
Worker's position
management_level
String
Management level name
management_level_id
String
Management level identifier
location
String
Worker's location
hire_date
Timestamp
Date the worker was hired
managers
String List
List of manager names
hiring_manager
String
Hiring manager's name
hiring_manager_email
String
Hiring manager's email address
employee_types
String List
List of employee types
cost_center
String
Worker's cost center
workday_id
String
Workday unique identifier
termination_date
Timestamp
Date the worker was terminated (if applicable)
primary_time_zone
String
Worker's primary time zone
is_active
Boolean
Whether the worker is active
created_at
Timestamp
Worker record creation date
idp_unique_id
String
Unique identifier for identity mapping
businessProcessTypes
Sync Identities action is not currently supported for Workday (no user provisioning to Workday)
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
❌
MANAGE_RELATIONSHIPS
Controls entitlements such as security group memberships
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities
❌
CREATE_ENTITLEMENT
Creates entitlements such as groups or roles
❌
WRITE_BACK_EMAIL
Updates email addresses in Workday worker records
✅
SOURCE_OF_IDENTITY
Workday can act as a source system for identity lifecycle policies
✅
View and Modify
Workday Query Language
View and Modify
Person Data: Work Email
View and Modify
Person Data: Work Contact Information
View and Modify
Worker Data: Staffing
View and Modify
Worker Data: Public Worker Reports
Get Only
Security Configuration
email
String
Worker's email address
first_name
String
Worker's first name
Get Only
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls role membership for user identities
✅
DEPROVISION_IDENTITY
Safely disables access for identities without deleting them
✅
DELETE_IDENTITY
Permanently removes user identities from the database
✅
SOURCE_OF_IDENTITY
MySQL can act as a source system for identity lifecycle policies
✅
This document includes steps to enable the MySQL integration for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
MySQL Version Compatibility: Lifecycle Management supports MySQL 5.7 and later. Role management (MANAGE_RELATIONSHIPS) requires MySQL 8.0 or later.
Required Access
You will need administrative access in Veza to configure the integration.
Ensure you have an existing MySQL integration in Veza or add a new one for use with Lifecycle Management.
Verify your MySQL integration has completed at least one successful extraction.
Required MySQL Service Account Privileges
The MySQL service account used for Lifecycle Management requires specific global privileges depending on which features you plan to use.
Minimal Required Privileges
These privileges are required for core Lifecycle Management functionality:
CREATE USER
Global (*.*)
Creating, modifying, and deleting user accounts
Also enables ALTER USER and DROP USER operations automatically
GRANT OPTION
Global (*.*)
Granting roles to users (MANAGE_RELATIONSHIPS)
Required to delegate privileges and assign roles to users
Optional Privileges for Extended Functionality
These privileges enable additional features but are not required for basic operations:
SUPER
Global (*.*)
Granting/revoking SUPER privilege via the is_full_admin attribute
High privilege - enables system-wide administrative operations. Only needed if you plan to use is_full_admin. Use a dedicated service account and restrict its host pattern for security.
CREATE ROLE
Global (*.*)
Creating new roles via MANAGE_RELATIONSHIPS (MySQL 8.0+ only)
Only needed if you want Lifecycle Management to create roles dynamically
DROP ROLE
Global (*.*)
Deleting roles via MANAGE_RELATIONSHIPS (MySQL 8.0+ only)
Granting Privileges
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a MySQL integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your MySQL data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for MySQL in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
MySQL can serve as a source for identity information in Lifecycle Management Policies, with user identity details synchronized from MySQL and propagated to connected systems. MySQL can also be a target for identity management actions based on changes in another external source of truth or as part of a workflow.
All lifecycle management operations are performed within database transactions, ensuring atomicity - either all changes succeed or all fail.
Important: Active MySQL sessions are not automatically terminated by account changes (locks or deletions). Existing sessions continue until the user logs out. For security incidents, manually terminate sessions using KILL CONNECTION before deprovisioning or deleting accounts.
The integration supports the following lifecycle management Actions:
The SYNC_IDENTITIES action synchronizes user account attributes between systems. This action can create new users and update existing users.
Entity Types: MySQLUserInstance
Create Allowed: Yes - New user identities can be created if not found in MySQL
MySQL User Identity Model
MySQL uniquely identifies users by the combination of username and host pattern: 'username'@'host_pattern'. This means 'alice'@'%' and 'alice'@'localhost' are two completely different user accounts with separate privileges and authentication.
Host Pattern Examples:
'%' - Can connect from any host (unrestricted)
'localhost' - Can only connect from MySQL server itself
'192.168.1.%' - Restricted to specific network range
'10.0.%' - Restricted to 10.0.0.0/16 network
For security, use specific network ranges (e.g., '10.0.%') instead of unrestricted access ('%') when possible.
Syncable Attributes
Attribute Behavior
The user and host attributes are required and combined to form the unique identity 'username'@'host_pattern'. The username cannot be changed after creation (renaming not supported). The host pattern supports wildcards including '%' (any host), 'localhost' (local only), IP patterns like '192.168.1.%', and hostname patterns like '%.example.com'.
The optional is_full_admin attribute grants or revokes SUPER privilege via GRANT SUPER ON *.* TO 'user'@'host' or REVOKE SUPER. SUPER enables system-wide administrative operations - for MySQL 8.0+, consider using dynamic privileges for more granular control.
Account Status Control: User account active/inactive status is controlled through the DEPROVISION_IDENTITY action (via ALTER USER ACCOUNT LOCK/UNLOCK), not through SYNC_IDENTITIES attributes. When deprovisioned, new logins are prevented but active sessions continue. To reactivate a deprovisioned user, use SYNC_IDENTITIES to update the user.
Passwords are automatically generated using cryptographically secure random generation at user creation time, using MySQL's default authentication plugin (caching_sha2_password for MySQL 8.0+, mysql_native_password for MySQL 5.7). Password updates are not supported via SYNC_IDENTITIES; use ALTER USER 'username'@'host' IDENTIFIED BY 'new_password' directly in MySQL.
The MANAGE_RELATIONSHIPS action controls user membership in MySQL roles. This action can grant roles to users, revoke roles from users, create new roles, and delete existing roles.
Supported Relationship Types:
MySQLRoleInstance: User membership in MySQL roles (MySQL 8.0+ required)
Assignee Types: MySQLUserInstance
Supports Removing Relationships: Yes
⚠️ MySQL Version Requirement: Role functionality requires MySQL 8.0 or later. This feature is not available in MySQL 5.7 or earlier versions.
Role Operations
MySQL roles (MySQL 8.0+) are named collections of privileges stored in the mysql.user table with a 'name'@'host' identity format. Role-to-user assignments are tracked in the mysql.role_edges system table.
Grant role to user
GRANT 'role_name'@'role_host' TO 'username'@'user_host'
Links role to user in mysql.role_edges. Role activation required*
Revoke role from user
REVOKE 'role_name'@'role_host' FROM 'username'@'user_host'
Removes link and immediately deactivates role in active sessions
Create role
CREATE ROLE 'role_name'@'role_host'
Creates entry in mysql.user. Role has no privileges by default
Delete role
DROP ROLE 'role_name'@'role_host'
* Granting a role does not automatically activate its privileges. To enable automatic activation, configure MySQL: SET GLOBAL activate_all_roles_on_login = ON. Alternatively, set default roles per user: SET DEFAULT ROLE ALL TO 'username'@'host'.
Disables a MySQL user account without deleting it (soft delete). User entry remains in database with all privileges preserved, but login attempts fail.
Entity Type: MySQLUserInstance
Remove All Relationships: No - Role memberships and privileges preserved
Deprovisioning Method: Account Lock via ACCOUNT LOCK feature
Reversible: Yes - Reactivate via ACCOUNT UNLOCK or SYNC_IDENTITIES with is_active: true
Executes ALTER USER 'username'@'host' ACCOUNT LOCK, which sets account_locked = 'Y' in the mysql.user table. New login attempts fail immediately while all role memberships, privileges, database objects, and user metadata are preserved. Reactivate via ALTER USER 'username'@'host' ACCOUNT UNLOCK or SYNC_IDENTITIES with is_active: true.
Permanently removes a MySQL user account from the database (hard delete). Irreversible - user cannot be recovered.
Entity Type: MySQLUserInstance
Permanence: Irreversible - User cannot be recovered
Remove All Relationships: Yes - All privileges and role memberships removed
Executes DROP USER 'username'@'host', which removes the user record from mysql.user and all grant table entries. All privileges and role memberships are removed, but database objects (tables, views, stored procedures, triggers, events) remain with orphaned DEFINER references.
Objects with DEFINER pointing to the deleted user may fail depending on SQL SECURITY mode - objects with DEFINER (default) may fail with "user specified as definer does not exist" error, while objects with INVOKER execute using the invoking user's privileges and are unaffected.
Critical: Always audit database objects before deleting users. Identify affected objects:
Reassign ownership to a service account before deletion: ALTER DEFINER='service_account'@'%' VIEW schema.view_name;
DELETE vs DEPROVISION Comparison
User entry
Removed from database
Preserved in mysql.user
Reversible
No (must recreate)
Yes (ACCOUNT UNLOCK)
Privileges
Removed
Preserved
Role memberships
Removed
Prefer DEPROVISION_IDENTITY unless permanent deletion is specifically required. Deprovisioning provides same access control while maintaining recoverability and audit trails.
Enable SCIM-based provisioning for custom applications with Open Authorization API
{instance_url}/ccx/api/person/v3/{tenant}/workContactInformationChanges/{change_id}/emailAddresses
{instance_url}/ccx/api/person/v3/{tenant}/workContactInformationChanges/{change_id}/submit
{instance_url}/ccx/api/staffing/v5/{tenant}/workers/{worker_id}/workContactInformationChanges-- Create dedicated service account with restricted host pattern
CREATE USER 'veza_lcm'@'10.0.%' IDENTIFIED BY 'secure_password_here';
-- Grant minimal required privileges
GRANT CREATE USER ON *.* TO 'veza_lcm'@'10.0.%' WITH GRANT OPTION;
-- Apply privilege changes
FLUSH PRIVILEGES;-- Create service account (MySQL 8.0+)
CREATE USER 'veza_lcm'@'10.0.%' IDENTIFIED BY 'secure_password_here';
-- Grant privileges including role management
GRANT CREATE USER, CREATE ROLE, DROP ROLE
ON *.* TO 'veza_lcm'@'10.0.%' WITH GRANT OPTION;
-- Apply privilege changes
FLUSH PRIVILEGES;-- Create service account
CREATE USER 'veza_lcm'@'10.0.%' IDENTIFIED BY 'secure_password_here';
-- Grant all privileges including SUPER
GRANT CREATE USER, SUPER, CREATE ROLE, DROP ROLE
ON *.* TO 'veza_lcm'@'10.0.%' WITH GRANT OPTION;
-- Apply privilege changes
FLUSH PRIVILEGES;-- Example with minimal privileges and unrestricted host
CREATE USER 'veza_lcm'@'%' IDENTIFIED BY 'secure_password_here';
GRANT CREATE USER ON *.* TO 'veza_lcm'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;-- Find stored procedures/functions with this DEFINER
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE DEFINER = 'username@host';
-- Find views with this DEFINER
SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.VIEWS
WHERE DEFINER = 'username@host';Only needed if you want Lifecycle Management to delete roles
mysql.user.User column
host
Yes
String
Host pattern defining where user can connect from
mysql.user.Host column
is_full_admin
No
Boolean
Whether user has SUPER privilege (full administrator rights)
mysql.user.Super_priv column
Removes entry and automatically revokes role from all users
Preserved
Objects owned
Preserved but orphaned (invalid DEFINER)
Preserved with ownership intact
Audit trail
Lost
Maintained
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)
Sync Identities
✅
Create new users or update existing user attributes in the target application
Manage Relationships
✅
Add or remove users from groups
De-provision Identity
✅
Deactivate user accounts (sets active=false in SCIM)
Delete Identity
✅
There are several potential ways to integrate a custom application for automated lifecycle management and access requests:
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.
Full SCIM Connector: Use the built-in SCIM connector for both basic data gathering and lifecycle management. This will provide visibility into supported SCIM entities and relationships with schedulable extractions, but not for the full range of entities and metadata that might be modeled using the Application Template such as roles and resources.
Custom REST API Actions: Actions in Veza may directly call any external API and capture the response in audit trails. This can enable Lifecycle Management and Access Requests for any target system, provided it has appropriate endpoints for managing users and access controls.
Extraction Method
You build the OAA push payload directly
Auto-discovery via SCIM endpoints
Authorization Modeling
Full OAA Application support (roles, permissions, resources)
Users and groups only
Lifecycle Management
Via SCIM endpoints
Via SCIM endpoints
Use Case
Complex custom applications where visibility or access reviews are needed.
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 (POST /Users, PATCH /Users/{id}, etc.)
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
GET /Users/{id} - Retrieve specific user by ID
PATCH /Users/{id} - Update user attributes
DELETE /Users/{id} - Delete user (required if using Delete Identity action)
Group Management:
GET /Groups - List groups
GET /Groups/{id} - Retrieve specific group by ID
POST /Groups - Create new groups
PATCH /Groups/{id} - Update group membership
DELETE /Groups/{id} - Delete group (optional)
Note: If the Users and Groups APIs are not at the standard
/Usersand/Groupspaths, 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
name
Yes
Display name for the Custom Provider in Veza
custom_template
Yes
OAA template type ("application")
provisioning
Yes
Must be set to true to enable Lifecycle Management
external_lifecycle_management_type
Yes
Lifecycle management mode (use "SCIM" to enable SCIM-based provisioning)
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.
scim_url
Yes
Base URL for SCIM API (without /Users or /Groups path)
""
scim_token
No*
Bearer token for authentication
"eyJhbGci..."
username
No*
Username for basic authentication
* 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 Getting Started Guide 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:
user_name
userName
String
Yes
Unique username
emails
emails
Array
No
Email addresses
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:
Query for existing user:
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:
Retrieve group details:
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:
Configuring the Azure integration for Veza Lifecycle Management
The Veza integration for Azure AD (Microsoft Entra ID) enables automated user provisioning, access management, and de-provisioning capabilities as a target system. This integration allows you to provision users from authoritative sources, manage group memberships, assign licenses, and automate the user lifecycle based on changes in external identity sources.
This document includes steps to enable the Azure integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration.
Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.
Verify your Azure integration has completed at least one successful extraction.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an Azure integration
Check the box to Enable usage for Lifecycle Management
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Azure AD serves as a target for identity management actions in Lifecycle Management , based on changes in another external source of truth (such as Workday, Okta, or Oracle HCM) or as part of a workflow.
Note: Azure AD is not currently supported as a source of identity for Lifecycle Management. It can only be used as a target system for provisioning, deprovisioning, and access management actions.
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
Entity Types: Azure AD User, Exchange Online Mailbox
Create Allowed (Azure AD User): Yes (new user identities can be created if not found)
Create Allowed (Exchange Online Mailbox): No (update only)
The following attributes can be synchronized:
Use Sync Identities with the Exchange Online Mailbox entity type to update mailbox settings for existing mailboxes. To create new mailboxes, use the action instead.
Creates guest user accounts in Azure AD by sending invitations:
Required Attributes:
invited_user_email_address - Email address of the person to invite
invite_redirect_url - URL where the user is redirected after accepting the invitation
Controls relationships between users and Azure AD entities:
Supported Relationship Types:
Groups: Add or remove users from Azure AD groups
Roles: Assign or remove Azure AD roles
Distribution Lists: When managing distribution list memberships, use the Exchange Online Distribution Group entity type. The Microsoft Graph API cannot modify distribution lists or mail-enabled security groups.
Creates or enables email functionality for users in Azure AD:
Implementation: Assigns Exchange Online license to the user
Requirements: Available Exchange Online license in your tenant
Results: Email-enabled user account with Exchange Online capabilities
Creates new entitlements in Azure AD, including groups and distribution lists:
Azure AD Group Creation:
Required Attributes: name
Optional Attributes:
When a user is deprovisioned:
Entity Type: Azure AD Users
Remove All Relationships: Yes (Removes group memberships, role assignments, and license assignments)
De-provisioning Method: Disabled (Users are marked as disabled rather than deleted)
Specifically handles deprovisioning of guest user accounts:
Required Attributes:
invited_user_email_address - Email address of the guest user
Optional Attributes:
Azure AD integration supports custom properties defined in your tenant. These can be configured in the integration settings and used in attribute transformers for Lifecycle Management actions.
Allows password reset operations for Azure AD users:
Entity Type: Azure AD Users
Unique Identifiers: Can use principal_name, mail_nickname, or invited_user_email_address. At least one unique identifier is required to identify the user
Password Profile Attributes:
Notes:
If no password is provided, a secure password will be generated automatically
Password must meet your Azure AD password policy requirements
Available options include forcing password change on next sign-in and requiring MFA
Configuring the Oracle Fusion Cloud integration for Veza Lifecycle Management
The Veza integration for Oracle Fusion Cloud enables automated user lifecycle management, supporting user provisioning, deprovisioning, and role assignment management through the Oracle SCIM API.
This document includes steps to enable the Oracle Fusion Cloud integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration and appropriate administrative privileges in Oracle Fusion Cloud.
Ensure you have an existing Oracle Fusion Cloud integration in Veza or for use with Lifecycle Management.
Verify your Oracle Fusion Cloud integration has completed at least one successful extraction.
Enabling the Oracle Fusion Cloud integration in Veza requires:
Your Oracle Fusion instance URL
Service account username with administrative privileges
Service account password for HTTP Basic Authentication
Oracle Fusion Cloud uses predefined BI Publisher reports for extracting role and privilege information. These reports must be accessible at the following paths:
/Custom/Veza/v2/ASE_ROLE_VL.xdo - Application roles
/Custom/Veza/v2/ASE_PRIVILEGE_VL.xdo - Privileges
/Custom/Veza/v2/ASE_PRIV_ROLE_MBR.xdo - Privilege to role mappings
Note: These reports are used for metadata extraction only. Lifecycle Management operations use the SCIM API.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an Oracle Fusion Cloud integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Oracle Fusion Cloud data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Oracle Fusion Cloud in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Oracle Fusion Cloud serves as a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
Username cannot be changed after creation
Email addresses must be unique
Required attributes must be present (user_name, email)
The following attributes can be synchronized:
Attribute Notes:
The SCIM API uses standard SCIM 2.0 field mappings
Email is stored as the first element in the SCIM emails array
Additional custom attributes beyond these three are not supported
The integration supports managing role assignments for users:
Both adding and removing role memberships are supported
Role assignments are managed through the Oracle SCIM API
Available roles are discovered during the extraction process
Supported Entitlement Types:
OAA.Oracle Fusion Cloud.Role - Oracle Fusion Cloud application roles
Role Management Operations:
List current role assignments for a user
Add role assignments to a user
Remove role assignments from a user
Deactivates a user account in Oracle Fusion Cloud:
Sets the user's active status to false
The user will no longer be able to log in
User data is retained for audit purposes
Deprovisioning Behavior:
User record remains in the system
All role memberships are preserved, but non-functional
The Account can be reactivated by setting the active status back to true
Permanently removes a user account from Oracle Fusion Cloud:
Completely deletes the user record
This action is irreversible
All role assignments are removed
Use with caution, as this removes audit history
Deletion Considerations:
Cannot be undone
Removes all user data and history
Should only be used when complete removal is required
Creates new roles in Oracle Fusion Cloud:
Role creation is supported through the lifecycle management framework
New roles can be created as part of provisioning workflows
Role properties include ID and role name
Role Creation Details:
Roles are created with basic properties (ID, name)
Custom role attributes are not currently supported
Role hierarchy and inheritance must be configured separately
Oracle Fusion Cloud lifecycle management uses the SCIM (System for Cross-domain Identity Management) protocol for user management operations. The integration:
Supports SCIM 2.0 standard operations
Handles user creation, update, deactivation, and deletion
Manages role assignments through SCIM relationship operations
The integration includes comprehensive error handling:
User not found errors are properly detected and reported
Duplicate user creation attempts are handled gracefully
Network and API errors are logged with appropriate context
Common Error Scenarios:
404 Not Found: User or role doesn't exist
409 Conflict: Duplicate user or constraint violation
400 Bad Request: Invalid attribute values or missing required fields
Users in Oracle Fusion Cloud are identified by:
User ID: System-generated unique identifier (uppercase)
Username: User-provided login name (case-sensitive)
Entity ID: Used for LCM operations, automatically converted to uppercase
The integration handles ID case conversion automatically to ensure compatibility with Oracle Fusion Cloud's uppercase ID requirements.
Testing: Always test lifecycle management policies in a non-production environment first
Extraction Schedule: Set an appropriate extraction interval based on your organization's change frequency (recommended: 6-12 hours)
Monitoring: Regularly review the LCM Activity Log for any errors or unexpected behavior
Username cannot be modified after user creation
Oracle Fusion Cloud cannot currently serve as a source of identity for LCM policies
Custom user attributes beyond the standard SCIM schema are not supported
Common issues and resolutions:
Enable Debug Logging: Turn on debug logs for the integration to see detailed API requests and responses
Check Activity Logs: Review the Lifecycle Management activity logs for specific error messages
Verify Permissions: Use the Oracle Fusion Cloud UI to confirm the service account has the necessary permissions
GET /Users?filter=userName eq "jane.doe"PATCH /Users/{id}
Content-Type: application/scim+json{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{"op": "replace", "path": "displayName", "value": "Jane Smith"}
]
}GET /Groups/{groupId}PATCH /Groups/{groupId}
Content-Type: application/scim+json{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "add",
"path": "members",
"value": [{"value": "{userId}"}]
}
]
}curl -X POST "https://{VEZA_URL}/api/v1/providers/custom" \
-H "authorization: Bearer {API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"name": "MyCustomApp",
"custom_template": "application",
"provisioning": true,
"external_lifecycle_management_type": "SCIM",
"configuration_json": "{\"scim_url\":\"https://api.myapp.com/scim/v2\",\"scim_token\":\"your-bearer-token\"}"
}'{
"scim_url": "https://api.customerportal.internal.com/scim/v2",
"scim_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"scim_extension_schemas": true
}{
"scim_url": "https://legacy.mycompany.com/api/scim",
"username": "scim-service-account",
"password": "secure-password-here"
}custom_app = CustomApplication(
name="CustomerPortal", # Display name
application_type="CustomerPortal" # This determines entity types!
)POST /Users
Content-Type: application/scim+json{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "jane.doe",
"name": {
"givenName": "Jane",
"familyName": "Doe",
"formatted": "Jane Doe"
},
"emails": [
{"value": "[email protected]", "primary": true}
],
"active": true
}PATCH /Users/{id}
Content-Type: application/scim+json{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{"op": "replace", "path": "active", "value": false}
]
}DELETE /Users/{id}PATCH /Groups/{groupId}
Content-Type: application/scim+json{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "remove",
"path": "members",
"value": [{"value": "{userId}"}]
}
]
}POST /Groups
Content-Type: application/scim+json{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"displayName": "Engineering Team"
}Permanently delete user accounts from the target application
Create Entitlement
✅
Create new groups in the target application
Standard SaaS with SCIM support
configuration_json
Yes
JSON-encoded string containing SCIM connection details (see structure below)
"scim-admin"
password
No*
Password for basic authentication
"secure-password"
users_endpoint
No
Users endpoint path (defaults to Users if not specified)
"Users"
groups_endpoint
No
Groups endpoint path (defaults to Groups if not specified)
"Groups"
scim_extension_schemas
No
Fetch SCIM schemas for extension attribute support (default: false)
true
ca_certificate
No
Custom CA certificate for SSL verification (PEM format)
"-----BEGIN CERTIFICATE-----..."
display_name
displayName
String
No
User's display name
title
title
String
No
Job title
nick_name
nickName
String
No
Casual name
external_id
externalId
String
No
External system identifier
phone_numbers
phoneNumbers
Array
No
Phone numbers (JSON array)
addresses
addresses
Array
No
Physical addresses (JSON array)
ims
ims
Array
No
Instant messaging addresses (JSON array)
photos
photos
Array
No
Photo URLs (JSON array)
locale
locale
String
No
User's locale
preferred_language
preferredLanguage
String
No
Preferred language
profile_url
profileUrl
String
No
Profile page URL
timezone
timezone
String
No
User's timezone
user_type
userType
String
No
User classification
formatted_name
name.formatted
String
No
Full formatted name
family_name
name.familyName
String
No
Last name
given_name
name.givenName
String
No
First name
middle_name
name.middleName
String
No
Middle name
SCIM API Permissions:
/hcmRestApi/scim/Users - Full user lifecycle management
GET: Read user by ID or username
POST: Create new users
PATCH: Update user attributes and manage role memberships (ADD/REMOVE operations)
DELETE: Remove users permanently
/hcmRestApi/scim/Groups - Role information access
GET: Read role details and membership information
BI Publisher Permissions:
Execute reports via /xmlpserver/services/PublicReportService?wsdl
Access to predefined reports in /Custom/Veza/v2/ directory
/Custom/Veza/v2/ASE_Role_Role_MBR.xdo - Role hierarchy
/Custom/Veza/v2/ERP_USER_ROLES.xdo - User role assignments
Primary login identifier
Unique, cannot be changed after creation
Yes
String
emails[0].value
User's email address
Must be unique across the system
display_name
No
String
displayName
User's display name
Defaults to username if not provided
401 Unauthorized: Authentication failure
403 Forbidden: Insufficient permissions
Role Management: Ensure roles are properly configured in Oracle Fusion Cloud before assigning them through LCM
Deprovisioning vs. Deletion: Use deprovisioning for standard offboarding; reserve deletion for special cases
Bulk Operations: When processing multiple users, consider batching to avoid API rate limits
Error Recovery: Implement retry logic for transient failures
Role hierarchy and complex role structures must be managed outside of LCM
Extraction fails
Network connectivity or API changes
Check network connectivity and Oracle Fusion Cloud service status
Deprovisioning doesn't disable login
Caching or replication delay
Allow up to 15 minutes for changes to propagate
Test SCIM Endpoints: Use a tool like Postman to test SCIM endpoints directly
Review Extraction Status: Check the last extraction results for any warnings or errors
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities
✅
DELETE_IDENTITY
Permanently deletes user accounts from Oracle Fusion Cloud
✅
CREATE_ENTITLEMENT
Creates new roles in Oracle Fusion Cloud
✅
SOURCE_OF_IDENTITY
Oracle Fusion Cloud can act as a source system for identity lifecycle policies
❌
user_name
Yes
String
User creation fails with "duplicate" error
Username or email already exists
Verify the username and email are unique in Oracle Fusion Cloud
Role assignment fails
Role doesn't exist or is inactive
Ensure the role exists and is active in Oracle Fusion Cloud
Authentication errors
Invalid credentials or expired password
Verify the service account credentials and permissions
User not found during update
User doesn't exist or ID mismatch
userName
Check if the user exists and the identifier is correct (note: IDs are uppercase)
✅
DISABLE_GUEST_ACCOUNT
Specifically handles deprovisioning of guest user accounts
✅
RESET_PASSWORD
Allows password reset operations for Azure AD users
✅
Directory.ReadWrite.All - Required for creating, updating, and managing directory objects
Group.ReadWrite.All - Required for creating and managing groups
GroupMember.ReadWrite.All - Required for managing group memberships
User.EnableDisableAccount.All - Required for enabling/disabling user accounts
mail_nickname
Yes
String
Mail nickname
display_name
Yes
String
Display name
account_enabled
No
Boolean
Enable/disable account
city
No
String
User's city
company_name
No
String
Company name
country_or_region
No
String
User's country or region
department
No
String
User's department
employee_hire_date
No
DateTime
Employee hire date
employee_id
No
String
Employee identifier
Can be unique identifier
employee_type
No
String
Employee type
first_name (given_name)
No
String
User's first name
job_title
No
String
Job title or position
manager_principal_name
No
String
Manager's principal name
nickname
No
String
User's nickname
office
No
String
Office location
other_mails
No
String List
Additional email addresses
password_policies
No
String
Password policy settings
password_profile_force_change_password_next_sign_in
No
Boolean
Force password change on next sign-in
password_profile_force_change_password_next_sign_in_with_mfa
No
Boolean
Force MFA on next password change
password_profile_password
No
String
Initial password setting
postal_code
No
String
Postal code
state
No
String
State or province
street_address
No
String
Street address
last_name (surname)
No
String
User's last name
usage_location
No
String
Usage location for licensing
user_type
No
String
Type of user
String
Mailbox identity
For example: [email protected]
mailbox_settings
No
String
Mailbox settings to sync
Space-separated key=value pairs (see examples below)
cas_mailbox_settings
No
String
Client Access Settings (CAS) to sync
Space-separated key=value pairs (see examples below)
Commonly Used Mailbox Settings:
The mailbox_settings attribute accepts parameters for the Exchange Online Set-Mailbox cmdlet. Common settings include:
AuditEnabled
Boolean
Enable mailbox auditing
true
AuditLogAgeLimit
TimeSpan
Audit log retention period
180.00:00:00
RecipientLimits
Integer
Maximum recipients per message
Example:
Commonly Used CAS Mailbox Settings:
The cas_mailbox_settings attribute accepts parameters for the Exchange Online Set-CASMailbox cmdlet. Common settings include:
OWAEnabled
Boolean
Enable Outlook on the Web access
true or false
ActiveSyncEnabled
Boolean
Enable Exchange ActiveSync
true or false
EwsEnabled
Boolean
Enable Exchange Web Services
Example:
Exact Value Matching Required: During the verification phase, Veza compares the requested values to the values returned by Exchange Online for exact matching. Use the same format that Exchange Online returns.
For example, when setting AuditLogAgeLimit, use the format 180.00:00:00 (days.hours:minutes:seconds), not just 180.
principal_name - User principal name (if not provided, generated from email)
display_name - Display name (if not provided, generated from email)
mail_nickname - Mail nickname (if not provided, generated from email)
Other standard user attributes as needed
Distribution Lists: Manage Exchange Online distribution list memberships
Assignee Types: Azure AD Users
Supports Removing Relationships: Yes
mail_enabled - Whether the group is mail-enabled
is_security_group - Whether it's a security group
visibility - Privacy setting (Public, Private, HiddenMembership)
description - Group description
Distribution Group Creation:
Required Attributes: name
Optional Attributes:
identity - Unique identifier
alias - Email alias
primary_smtp_address - Primary email address
group_type - Type of distribution group
User Logout - Force user to log out from all active sessions
Remove All Licenses - Remove all license assignments
Remove All Personal Devices - Remove device registrations
display_name - Display name of the guest user
Complex Password Support: Supports complex password requirements per Azure AD policy
mail_nickname
No*
String
Mail nickname
Can be used as unique identifier
invited_user_email_address
No*
String
Email address for guest users
Can be used as unique identifier for guest accounts
password_profile_force_change_password_next_sign_in
No
Boolean
Require user to change password at next login
password_profile_force_change_password_next_sign_in_with_mfa
No
Boolean
Require MFA when changing password at next login
password_profile_password
No
String
New password value
Must meet Azure AD complexity requirements; autogenerated if not provided
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships, role assignments, and license assignments
✅
CREATE_GUEST_USER
Creates guest user accounts by sending invitations
✅
CREATE_ENTITLEMENT
Creates new entitlements in Azure AD, including groups and distribution lists
✅
CREATE_EMAIL
Creates or enables email functionality for users
✅
DEPROVISION_IDENTITY
principal_name
Yes
String
User Principal Name
identity
principal_name
No*
String
User Principal Name
Safely removes or disables access for identities, includes user logout support
Unique identifier
Yes
Can be used as unique identifier
AuditEnabled=true AuditLogAgeLimit="180.00:00:00" RecipientLimits=250 MaxSendSize="25 MB (26,214,400 bytes)"OWAEnabled=false ActiveSyncEnabled=false EwsEnabled=false MAPIEnabled=true PopEnabled=false ImapEnabled=true250
MaxSendSize
Size
Maximum outgoing message size
25 MB (26,214,400 bytes)
MaxReceiveSize
Size
Maximum incoming message size
25 MB (26,214,400 bytes)
ProhibitSendQuota
Size
Mailbox size limit for sending
49 GB (52,613,349,376 bytes)
IssueWarningQuota
Size
Mailbox size warning threshold
45 GB (48,318,382,080 bytes)
true or false
MAPIEnabled
Boolean
Enable MAPI (Outlook desktop)
true or false
PopEnabled
Boolean
Enable POP3 access
true or false
ImapEnabled
Boolean
Enable IMAP4 access
true or false
Configuring the Okta integration for Veza Lifecycle Management.
The Veza integration for Okta enables automated user lifecycle management, with support for user provisioning and de-provisioning, group membership management, and attribute synchronization.
This document includes steps to enable the Okta integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration and grant API scopes in Okta.
Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.
Verify your Okta integration has completed at least one successful extraction
Enhanced Security: For organizations with security policies preventing super admin grants, see the which provides least-privilege alternatives that include these additional LCM scopes.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an Okta integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your Okta data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for Okta in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
Okta can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from Okta with changes propagated to connected systems
Okta can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow:
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
Login ID cannot be changed after creation
Email addresses must be unique
Required attributes must be present (login, email, first_name, last_name)
The following attributes can be synchronized:
Both adding and removing memberships are supported. Group memberships are removed in deprovisioning.
Add and remove group memberships
Synchronize group assignments
Track membership changes
When a user is deprovisioned:
User account is disabled
Group memberships are removed
Attribute history is preserved for audit
Account can be reactivated if needed
Entity Types: Okta Groups
Assignee Types: Okta Users
Supports Relationship Removal: Yes
Within Okta, groups can be associated with:
Application group assignments controlling SSO access
Permissions to resources within specific applications
Synchronized AWS SSO groups
Resets passwords for Okta users by expiring their current password and generating a temporary password:
Requires the login attribute as a unique identifier
Non-idempotent action (each execution creates a new password reset event)
Expires the user's current password immediately
The temporary password is available in notification templates using the {{LOGIN_PASSWORD}} placeholder. Configure a notification for the LIFECYCLE_MANAGEMENT_RESET_PASSWORD event to automatically send the temporary password to users through your organization's approved channels. See for details.
Configuring the AWS IAM Identity Center integration for Veza Lifecycle Management.
The Veza integration for AWS IAM Identity Center enables automated user lifecycle management, with support for user provisioning and de-provisioning, group membership management, and attribute synchronization across AWS organizations.
This document includes steps to enable the AWS IAM Identity Center integration for use in Lifecycle Management, along with supported actions and notes. See for more details.
You will need administrative access in Veza to configure the integration and appropriate permissions in AWS IAM Identity Center.
Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.
Verify your AWS integration has completed at least one successful extraction
Important: AWS IAM Identity Center Lifecycle Management requires:
SCIM endpoint configuration in IAM Identity Center (automatic provisioning must be enabled)
The integration uses AWS's SCIM v2.0 API implementation over HTTPS
Authentication is handled through IAM policies and does not require separate SCIM bearer tokens
To enable the integration:
In Veza, go to the Integrations overview
Search for or create an AWS integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your AWS IAM Identity Center data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for AWS in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
AWS IAM Identity Center can serve as a source for identity information in Lifecycle Management . User identity details are synchronized from AWS IAM Identity Center with changes propagated to connected systems.
AWS IAM Identity Center can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
Username serves as the unique identifier and cannot be changed after creation
Email addresses must be unique across the AWS IAM Identity Center instance
First name, last name, display name, and username are required attributes for user creation
The following attributes can be synchronized:
Controls group memberships for users in AWS IAM Identity Center:
Add and remove group memberships for users
Synchronize group assignments based on source system changes
Support for both adding and removing relationships
When a user is deprovisioned in AWS IAM Identity Center:
User account is disabled (set to inactive) rather than deleted
All group memberships are automatically removed
User's permission set assignments are revoked
Entity Types: AWS IAM Identity Center Groups
Assignee Types: AWS IAM Identity Center Users
Supports Relationship Removal: Yes
Within AWS IAM Identity Center, groups can be associated with:
Permission sets that grant access to AWS accounts and resources
AWS applications and third-party SAML applications
AWS account assignments for cross-account access
Automate the onboarding process for new employees:
Identity Creation: Create AWS IAM Identity Center user account with attributes synchronized from HR system
Group Assignment: Add user to department-specific groups based on their role and location
Permission Sets: Automatically assign appropriate permission sets for AWS resource access
Handle internal role changes and departmental transfers:
Attribute Update: Synchronize updated employee information from HR system
Group Reassignment: Remove user from previous department groups and add to new ones
Permission Adjustment: Update permission set assignments to match new role requirements
Securely remove access when employees leave:
Account Deprovisioning: Disable the user account in AWS IAM Identity Center
Group Removal: Remove all group memberships and permission set assignments
Access Revocation: Ensure all AWS account access is immediately revoked
Configuring SCIM integrations for Veza Lifecycle Management.
The Veza SCIM integration enables automated user lifecycle management for any application that supports the System for Cross-domain Identity Management (SCIM) protocol. SCIM provides a standardized approach for provisioning, updating, and deprovisioning users and groups across diverse applications including Atlassian products, Egnyte, Sigma Computing, and many others.
okta.users.manage - For user lifecycle operations
okta.groups.manage - For group membership management
Yes
String
User's email address
Unique
first_name
Yes
String
Given name
last_name
Yes
String
Family name
display_name
No
String
User's display name
user_type
No
String
User type
department
No
String
Organizational department
title
No
String
Job title
manager
No
String
Manager's name
manager_id
No
String
Manager's identifier
employee_id
No
String
Employee identifier
division
No
String
Business division
organization
No
String
Organization name
cost_center
No
String
Cost center
country_code
No
String
Country code
second_email
No
String
Secondary email address
nickName
No
String
User's nickname
String
Group description
type
No
String
Group type
source
No
String
Group source
last_membership_updated_at
No
Timestamp
Last membership update time
Any password provided in the request is ignored; Okta always generates the temporary password
The user must sign in with the temporary password and will be prompted to set a new permanent password
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities, includes user logout support
✅
CREATE_ENTITLEMENT
Creates entitlements such as Okta groups
✅
RESET_PASSWORD
Allows password reset operations for Okta users
✅
SOURCE_OF_IDENTITY
Okta can act as a source system for identity lifecycle policies
✅
login
Yes
String
Primary login identifier
unique_id
Yes
String
Group identifier
description
Unique identifier
No
identitystore:CreateUser - For user creation operations
identitystore:UpdateUser - For user attribute synchronization
identitystore:DeleteUser - For user deletion (note: AWS uses SCIM deprovisioning which disables rather than deletes)
identitystore:GetUserId - For user lookup operations
identitystore:CreateGroup - For group creation
identitystore:CreateGroupMembership - For group membership management
identitystore:DeleteGroupMembership - For removing group memberships
identitystore:ListGroups - For group discovery operations
identitystore:ListGroupMemberships - For membership enumeration
display_name
Yes
String
User's display name
Required for creation
first_name
Yes
String
Given name
Required for creation
last_name
Yes
String
Family name
Required for creation
No
String
User's email address
Unique if provided
department
No
String
Organizational department
division
No
String
Business division
title
No
String
Job title
Users can be reactivated if needed by updating the Active attribute
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities
✅
CREATE_ENTITLEMENT
Creates entitlements such as groups
✅
SOURCE_OF_IDENTITY
AWS IAM Identity Center can act as a source system for identity lifecycle policies
✅
username
Yes
String
Primary user identifier
name
Yes
String
Group name identifier
Unique identifier
This guide covers direct SCIM integrations where Veza connects directly to an application's SCIM endpoints. For custom applications built with the Open Authorization API (OAA) that expose SCIM endpoints, see Custom Application with SCIM (OAA).
Use direct SCIM when connecting to standard SaaS applications with native SCIM support, and you only need user and group provisioning without complex entity modeling.
You can use OAA SCIM for integrating custom or home-grown applications via OAA, and need comprehensive visibility beyond users and groups (permissions, resources, etc.)
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as group memberships and role assignments for identities
✅
DEPROVISION_IDENTITY
Safely removes or disables access for identities
✅
CREATE_ENTITLEMENT
Creates entitlements such as groups
This document includes steps to enable SCIM integrations for use in Lifecycle Management, along with supported actions and notes. See Supported Actions for more details.
You will need administrative access in Veza to configure the integration and appropriate permissions in the target SCIM application.
Ensure you have an existing SCIM integration in Veza or add a new one for use with Lifecycle Management.
Verify your SCIM integration has completed at least one successful extraction
The SCIM integration will need the required API permissions:
Read permissions: scim:read or equivalent for user and group discovery
Write permissions: scim:write or equivalent for provisioning operations
Specific endpoints: Access to /Users
For Enterprise Extension attributes: Enable in your SCIM integration configuration to extract and synchronize attributes like department, division, employeeNumber, and manager.
Important: SCIM applications have varying permission models. Consult your specific application's documentation for the exact scopes or permissions required for SCIM operations.
To enable the integration:
In Veza, go to the Integrations overview
Search for or create a SCIM integration
Check the box to Enable usage for Lifecycle Management
Configure the extraction schedule to ensure your SCIM data remains current:
Go to Veza Administration > System Settings
In Pipeline > Extraction Interval, set your preferred interval
Optionally, set a custom override for your SCIM integration in the Active Overrides section
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview
Search for the integration and click the name to view details
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled
SCIM integrations can be targets for identity management actions, receiving provisioning commands from Veza based on changes in external sources of truth or as part of automated workflows.
The integration supports the following lifecycle management Actions:
Primary action for user management (creating or updating users):
Username (user_name) is required and serves as the unique identifier
Email addresses are managed through the SCIM emails array
User activation/deactivation is controlled via the active attribute
Custom attributes are mapped according to SCIM schema extensions
Veza supports comprehensive SCIM 2.0 user attributes for both read-only data extraction (Access Graph) and bidirectional synchronization (Lifecycle Management). The tables below indicate which attributes support LCM synchronization (✅) versus read-only extraction (📖).
Veza supports all standard SCIM 2.0 core user attributes, organized by functional category:
Identity & Authentication
Contact Information
Personal Information
Professional Information
System Metadata
Multi-valued Attributes: Attributes like emails, phoneNumbers, and addresses support multiple values with type indicators (e.g., work, home, other). Veza supports full create, update, and delete operations for these multi-valued fields.
Veza supports the SCIM Enterprise User Extension schema (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User) for both extraction and LCM synchronization:
employeeNumber
To extract and synchronize Enterprise Extension attributes, you must enable SCIM Extension Schemas in your . This option enables Veza to call the /Schemas endpoint and discover extension attributes.
Veza automatically discovers and extracts all custom vendor-specific SCIM extension attributes for read-only purposes:
Extraction Capabilities:
Veza calls the SCIM /Schemas endpoint to discover all available schemas (requires SCIM Extension Schemas enabled in integration configuration)
Custom extension schemas are automatically identified and extracted
Extension attributes appear in the Veza Access Graph for search and analysis
All data types are supported (string, boolean, number, dateTime, complex)
LCM Synchronization:
Custom vendor extensions can be synchronized through LCM workflows when SCIM Extension Schemas is enabled by referencing the normalized attribute name (visible as a custom property in Access Graph).
Veza automatically maps the normalized name back to the proper SCIM extension structure using the reverse index
For example, targeting scim_extension_vendor_customfield in an attribute transformer will transmit the corresponding SCIM extension via the API.
Example Custom Extensions:
Vendor-specific user attributes (e.g., Atlassian organization roles)
Custom application properties
Industry-specific fields (e.g., healthcare credentials, financial certifications)
Custom extension synchronization requires SCIM Extension Schemas to be enabled. This builds an index that maps normalized attribute names to their original SCIM schema structure.
Extension attributes must be referenced by their normalized names in LCM attribute transformers.
Core SCIM attributes use simplified names:
user_name, display_name, email, title, department, division, etc.
Extension attributes require full normalized names:
Example: Enterprise Extension Attributes
Example: Custom Vendor Extensions
Group membership management with full add/remove capabilities:
Add users to groups for role-based access control
Remove users from groups during role changes or de-provisioning
Support for nested group structures where the SCIM provider allows
Relationship changes are immediate and reflected in target application
When a user is deprovisioned:
User account is deactivated (sets active: false)
Group memberships are automatically removed
Account can be reactivated if needed
User data is preserved for audit purposes
Note: Some SCIM implementations support hard deletion while others only support deactivation. The SCIM integration uses deactivation by default for data preservation.
Entity Types: SCIM Groups
Assignee Types: SCIM Users
Supports Relationship Removal: Yes
Within SCIM applications, groups can be associated with:
Application-specific permissions and roles
Resource access controls
Team or organizational structures
Custom entitlements defined by the SCIM provider
Veza supports all standard SCIM 2.0 group attributes for both extraction and LCM operations:
displayName
Yes
Group Membership Management: Veza supports both adding and removing members from groups through the Manage Relationships action. The members attribute contains an array of user references, each with a value (user ID) and optional display (user's display name) property.
The following applications are validated to work with Veza's SCIM Lifecycle Management:
Atlassian Products (Jira Cloud, Confluence Cloud, Bitbucket Cloud)
SCIM Endpoint: https://{domain}.atlassian.net/scim/directory/{directory-id}
Full user and group provisioning support
Egnyte
SCIM Endpoint: https://{domain}.egnyte.com/pubapi/scim/v2
User provisioning and group management
Sigma Computing
SCIM Endpoint: https://aws-api.sigmacomputing.com/scim/v2
User lifecycle and team assignment
Fivetran
SCIM Endpoint: https://api.fivetran.com/scim/v2
User and group provisioning
Harness
SCIM Endpoint: https://app.harness.io/gateway/ng/api/scim/account/{accountid}
User management and role assignment
Zapier
SCIM Endpoint: https://zapier.com/scim/v2
User provisioning and team management
Twingate
SCIM Endpoint: https://{domain}.twingate.com/api/scim/v2
User provisioning and group assignment
ThousandEyes
SCIM Endpoint: https://api.thousandeyes.com/scim
User management (groups via custom implementation)
When a new employee joins (triggered by HR system changes):
Identity Sync: Create user account in SCIM application with basic attributes
Email Setup: Configure primary email and secondary contacts
Group Assignment: Add user to department and role-based groups automatically
Access Verification: Confirm user can access application and assigned resources
When an employee changes roles or departments:
Attribute Update: Sync new job title, department, and manager information
Group Reassignment: Remove old role groups, add new role groups
Access Review: Verify appropriate access levels for new position
Notification: Alert managers and IT of completed changes
When an employee leaves the organization:
Account Deactivation: Set user status to inactive in SCIM application
Group Removal: Remove all group memberships and access rights
Data Preservation: Maintain account record for audit and compliance
Manager Notification: Alert appropriate stakeholders of access removal
For large-scale provisioning operations:
Batch Processing: Create multiple users efficiently through SCIM bulk operations
Group Pre-creation: Establish organizational groups before user assignment
Validation: Verify all users are created with correct attributes and memberships
Rollback Capability: Support for reversing bulk operations if needed
{
"attribute_name": "urn_ietf_params_scim_schemas_extension_enterprise_2_0_user_department",
"source": "identity_attribute",
"value": "department"
}{
"attribute_name": "urn_scim_schemas_extension_myvendor_1_0_customfield",
"source": "static_value",
"value": "Engineering"
}/GroupsSchema endpoint (optional): Access to /Schemas for extension attribute discovery
No
Array
✅
Physical addresses (supports multiple with type indicators)
ims
No
Array
✅
Instant messaging addresses
photos
No
Array
✅
Photo URLs
No
String
✅
Last name
name.middleName
No
String
✅
Middle name
name.formatted
No
String
✅
Formatted full name
nickName
No
String
✅
User's nickname or informal name
No
String
✅
User's locale preference (e.g., en-US)
timezone
No
String
✅
User's timezone (e.g., America/New_York)
preferredLanguage
No
String
✅
Preferred language code (e.g., en, es)
profileUrl
No
String
✅
URL to user's profile
✅
userName
Yes
String
✅
Primary login identifier, unique across the system
id
No
String
✅
SCIM system identifier (auto-generated, read-only after creation)
externalId
No
String
✅
External system identifier for cross-system identity mapping
active
No
Boolean
✅
User account status (controls activation/deactivation)
emails
No
Array
✅
Email addresses (can include multiple with type indicators)
phoneNumbers
No
Array
✅
Phone numbers (supports multiple with type indicators)
displayName
No
String
✅
User's display name (full name for UI presentation)
name.givenName
No
String
✅
First name
title
No
String
✅
Job title or professional role
userType
No
String
✅
User classification (e.g., Employee, Contractor)
meta.created
No
DateTime
📖
Account creation timestamp (read-only)
meta.lastModified
No
DateTime
📖
Last modification timestamp (read-only)
String
✅
Organization's employee identifier
costCenter
String
✅
Cost center assignment
organization
String
✅
Organization name
division
String
✅
Division within the organization
department
String
✅
Department assignment
manager
Complex
✅
Manager reference (contains value, $ref, displayName)
String
✅
Group display name (unique identifier)
id
No
String
✅
SCIM system identifier (auto-generated, read-only after creation)
externalId
No
String
✅
External system identifier for cross-system group mapping
groupType
No
String
✅
Group classification or category
description
No
String
✅
Group purpose or description
members
No
Array
✅
Group members (contains user references with value and display properties)
addresses
name.familyName
locale
Configuring the Salesforce integration for Veza Lifecycle Management.
The Veza integration for Salesforce enables automated user lifecycle management across your identity ecosystem. This integration allows security and IT teams to automate the provisioning, updating, and deprovisioning of Salesforce user accounts based on changes in an authoritative source (such as an HRIS system or another identity provider).
Key capabilities include:
User Provisioning: Automatically create Salesforce user accounts with appropriate profiles and permissions
Attribute Synchronization: Keep user details in sync across systems, ensuring data consistency
Permission Management: Assign and remove permission sets and roles based on policies
User Deprovisioning: Safely disable access when users leave the organization
The integration leverages the SCIM protocol for standardized identity management operations and uses Salesforce-specific APIs for permission management.
This document includes steps to enable the Salesforce integration for Lifecycle Management, along with details on supported actions and notes.
Before configuring the integration, ensure you have:
Administrative access in Veza to configure the integration
An existing in Veza or add a new one
At least one successful extraction from your Salesforce integration
The Salesforce integration will need the following permissions:
Assign Permission Sets: Enables assignment and removal of permission sets for users.
Freeze Users: Enables freezing and unfreezing user accounts.
Manage Internal Users: Required for user creation and updates.
In Salesforce, you can add these permissions for the Veza connected app in the System Permissions section at the bottom of the Permission Set configuration page.
Veza Lifecycle Management uses Salesforce SCIM APIs for identity provisioning operations. The SCIM protocol enables the automated exchange of user identity data between Veza and Salesforce. The permissions listed above provide the necessary access for SCIM functionality.
The Connected App used for the integration must have OAuth scopes that include api and refresh_token permissions and a certificate for JWT-based authentication
To make the required API calls, the integration requires a custom user profile in Salesforce with "API Enabled" permission
For additional details about Salesforce's SCIM implementation, refer to the .
To enable the integration:
In Veza, go to the Integrations overview.
Search for or create a integration.
Ensure the integration permission set includes the .
Configure the extraction schedule to ensure your Salesforce data remains current:
Go to Veza Administration > System Settings.
In Pipeline > Extraction Interval, set your preferred interval.
Optionally, set a custom override for Salesforce in the Active Overrides section.
To verify the health of the Lifecycle Management data source:
Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview.
Search for the integration and click the name to view details.
In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled.
Veza's Salesforce integration implements the SCIM 2.0 protocol to standardize identity management operations:
Users are represented with standard SCIM core attributes plus Salesforce-specific Enterprise extensions
The system uses email addresses as the primary key for user lookups
Usernames cannot be changed after creation and must be unique within the Salesforce instance
Salesforce can serve as a source for identity information in Lifecycle Management Policies. User identity details are synchronized from Salesforce, with changes propagated to connected systems.
Salesforce can also be a target for identity management actions based on changes in another external source of truth or as part of a workflow:
The integration supports the following lifecycle management :
Primary action for user management (creating or updating users):
Usernames cannot be changed after creation.
Email addresses must be unique.
Required attributes must be present (Username, Email, FirstName, LastName).
The following attributes can be synchronized:
Custom properties: In addition to the standard attributes above, Veza supports synchronizing custom properties for Salesforce User objects, including both direct properties and indirect (referenced) properties using dot notation (e.g., Profile.Name, Manager.Email). For details on configuring custom properties, see in the Salesforce integration guide.
The following relationship types are supported:
Groups: Add and remove group memberships (only for groups with Group Type = Regular).
Permission Sets: Add and remove permission set assignments.
Permission Set Groups: Add and remove permission set group assignments.
Notes:
Profile and role assignments are managed via SCIM and Salesforce APIs.
When removing a profile assignment, users are assigned the "Minimum Access - Salesforce" profile by default. This profile must exist in your Salesforce instance for profile changes to work properly.
Only Salesforce groups with the property Group Type = Regular can be used in Manage Relationships configurations.
When a user is deprovisioned:
The user account is frozen or deactivated (Salesforce does not allow user deletion).
Permission set assignments are removed.
Attribute history is preserved for audit.
SOURCE_OF_IDENTITY
Salesforce can act as a source system for identity lifecycle policies
✅
Salesforce API v40 or later for user provisioning
Manage Login Access Policies: Required for configuring login access policies.
Manage Password Policies: Required for setting and resetting passwords during user creation.
Manage Profiles and Permission Sets: Required for permission set and profile assignment.
Manage Roles: Required for role assignments and management.
Manage Sharing: Required for managing sharing rules and access control.
Manage Users: Essential for user lifecycle operations.
Monitor Login History: Required for monitoring user logins.
Reset User Passwords and Unlock Users: Required for account management.
View All Profiles: Required to view profile information for all users.
View All Users: Required to view all user information.
Save the configuration.
User roles are handled through SCIM roles endpoints
User Deprovisioning is implemented as deactivation (setting active=false)
Permission sets are assigned through Salesforce API calls after user creation
Division and Department attributes are excluded during updates due to Salesforce API limitations.
Salesforce does not support changing usernames after creation.
Yes
String
Given name
last_name
Yes
String
Family name
profile_id
Yes
String
User's profile ID
is_active
No
Boolean
Account status
department
No
String
Organizational department
user_role_id
No
String
User's role ID
User Roles: Synchronize user role assignments.
Groups of type RoleAndSubordinatesInternal are not supported but can be assigned through their corresponding roles.
Direct creation of permission sets ("Create Entitlement" action) is not currently supported.
SYNC_IDENTITIES
Synchronizes identity attributes between systems, with options to create new identities and update existing ones
✅
MANAGE_RELATIONSHIPS
Controls entitlements such as permission set assignments, role assignments, and profile assignments for identities
✅
DEPROVISION_IDENTITY
Safely freezes or disables access for identities, includes user deactivation support
✅
CREATE_ENTITLEMENT
Creates entitlements such as Salesforce permission sets
username
Yes
String
Primary login identifier
Unique identifier
emails
Yes
String List
User's email addresses
❌
first_name