Veza's Lifecycle Management (LCM) solution empowers organizations to automate and streamline the management of user identities and access rights throughout the employee lifecycle. From onboarding to role changes and offboarding, automated LCM workflows ensure that the right people have the correct access at the right time.

Key Features

• Automated Provisioning and De-provisioning: Streamline granting and revoking entitlements as employees join, move within, or leave the organization

• Environment-wide Synchronization: Keep user attributes and access rights consistent across applications and platforms

• Customizable Workflows: Design tailored processes for different lifecycle events and user segments

• Compliance and Audit Support: Maintain detailed records of access changes to support compliance and audit efforts

• Integration with Identity Providers: Integrate with identity providers and HR systems, import HR data from CSV, or use a custom OAA template

Core Concepts

Policies

Policies define the rules and actions for managing identities throughout their lifecycle. They specify what actions should occur when there are changes in a source of identity, such as when a user is created or their attributes change.

After configuring a policy for a source of identity in your organization, Veza Lifecycle Management tracks the source for changes. When employee records are added or changed, actions will trigger based on the workflows and actions specified in the policy.

Learn more about Policies

Workflows

Workflows are sequences of actions within a policy that execute based on specific conditions. They enable automation of lifecycle management processes such as onboarding, role changes, and offboarding.

Workflows only execute actions on users that meet specific conditions, and Policies can contain more than one Workflow. This enables you to create a single policy for your source of identity that contains multiple workflows, with one applying to new hires, another applying to terminated employees, and so on for the different JML scenarios you want to automate.

Learn more about Workflows

Access Profiles

Access Profiles define sets of entitlements (such as group memberships or role assignments within a target application) that should be granted to users based on their role within the organization (or another distinguishing attribute). You can use Access Profiles to define both Business Roles – segments of employees, and Profiles – collections of entitlements in a target application.

Assigning Business Roles to the Profiles they should inherit enables you to define the birthright entitlements for different types of employees in your organization. You can then assign those Business Roles when configuring workflows that add or remove access to an application.

Learn more about Access Profiles

Actions

Lifecycle Management Actions are tasks performed within a workflow, such as creating a user account, assigning group memberships, or disabling an account. Actions can be combined to trigger in sequence when there are changes in the source of identity. Actions can run for any identity that meets the workflow conditions, or only apply when action-level conditions are met.

Learn more about available Actions

Attribute Transformers

Transformers allow you to modify and format user attributes when synchronizing data between systems, ensuring consistency and compatibility when creating users across applications.

Lifecycle Management will provision new users with these attributes and can keep their accounts up-to-date when there are changes in the source of identity. Target entity attributes can be set to specific values or use metadata from the source of identity, and support a range of transformation functions.

Learn about Transformers

Notification Templates

Customize email notifications sent during Lifecycle Management events and Access Request workflows. You can personalize messaging, add branding, and include event-specific information through placeholders.

Learn more about Notification Templates

Getting Started

1. Enable Integrations: Configure your data sources and enable them for Lifecycle Management. Lifecycle Management Integrations

2. Define Access Profiles: Create profiles that map your organizational structure to application-specific entitlements. Creating Access Profiles

3. Create Policies: Add policies to automate identity management processes. Building Lifecycle Management Policies

4. Configure Workflows: Design workflows within policies to handle specific lifecycle events. Configuring Workflows

For an overview of Lifecycle Management configuration using Okta, Workday, and Active Directory, see Lifecycle Management with Workday, Okta, and Active Directory.

For API documentation, see Lifecycle Management APIs.

The Lifecycle Management Dashboard provides a centralized interface for monitoring automatic provisioning and deprovisioning of user access - both birthright access granted by Veza Lifecycle Management and just-in-time access granted by Veza Access Reviews. This dashboard gives you an at-a-glance view of your configuration, status, and recent activity.

The dashboard is the primary landing page for Lifecycle Management and Access Requests and can help with routine monitoring, error resolution, policy validation, activity review, and integration health checks.

Dashboard Overview

The dashboard is organized into several key sections:

• Policies: Displays your most recently updated Lifecycle Management Policies and their status

• Access Profiles: Shows configured Access Profiles and usage metrics

• Identities: Provides a visualization of managed identities

• Integrations: Top Integrations enabled for Lifecycle Management and Access Requests along with any error statuses

• Access Requests: Tracks pending and completed access requests

• Errors: Displays recent Lifecycle Management and Access Requests errors requiring attention (past day, week, or month)

• Recent Activity: Shows the most recent Lifecycle Management and Access Requests Events

To navigate to more detailed information, click on any section heading to open the related overview. Click on specific items (such as a policy or integration) to view or edit configuration details.

Dashboard Actions

From the dashboard, you can perform common tasks including:

• Create a new policy: Click the "Create Policy" button in the Policies section

• Configure Access Profiles: Click the "Create Access Profile" button in the Access Profiles section

• Set up a new integration: Click the "Set up Integration" button in the Integrations section

• Monitor system health: Review the Errors section for any issues

• Track recent changes: Review the Recent Activity section for a log of recent events

• Filter activity by time period: Use the time period dropdown (e.g., "Past day") to adjust the view

Policies

The Policies section displays all configured Lifecycle Management policies with their current status. Each policy shows its name, associated identity source, number of identities managed, and current status (Running/Stopped).

You can view all policies at a glance, create new ones with the "Create Policy" button, see which policies are actively running, access detailed configuration by clicking on a specific policy, and verify that policies in "Running" status should be active. Learn more about creating and managing policies.

Access Profiles

The Access Profiles section shows the total number of configured access profiles and provides a visual representation of profile activity. Access profiles define sets of entitlements granted to users based on their roles.

You can see the total number of configured profiles, create new ones using the "Create Access Profile" button, view profile activity and utilization, and access detailed configuration by clicking into the section. Learn more about Configuring Access Profiles.

Identities

The Identities section provides a visual representation of all identities managed through Lifecycle Management and Access Requests. The chart displays the distribution of identities by type or status, giving you an immediate understanding of your identity landscape.

This visualization helps you understand the overall composition of your managed identities, identify distribution patterns across different categories, and track changes in identity distribution over time.

Integrations

The Integrations section lists all systems connected to Lifecycle Management and Access Requests, displaying the total number of integrations, error status and counts, recently created integrations, and last update timestamps. For each integration, you can see its name and type, current status (including error indicators), and last update timestamp. You can set up new integrations using the "Set up Integration" button, identify and troubleshoot integration errors, and view all integrations by clicking "View all." Review this section regularly to identify any integrations with error states. See Lifecycle Management integrations for more information.

Access Requests

The Access Requests section tracks pending access requests, recently completed requests, and request status (Pending, Completed, Rejected, Cancelled). This section provides visibility into the access request process, allowing you to monitor request volume and status, track completion rates, and identify potential bottlenecks in the access request workflow.

Errors

The Errors section displays any Lifecycle Management and Access Requests errors that require attention. When functioning normally with no issues, this section will display "No issues found." If errors occur, this section will list the specific errors, provide context about when and where they occurred, and offer guidance on troubleshooting and resolution. Check this section regularly for any reported issues.

Recent Activity

The Recent Activity section shows a chronological log of Lifecycle Management and Access Requests events, including event type, timestamp, affected identity, and entity name. Examine this section to identify any unusual patterns or failed operations. This activity log helps you track recent actions, verify that expected changes have occurred, identify patterns or issues in lifecycle events, and monitor the overall health of your Lifecycle Management or Access Requests implementation.

Next Steps

After familiarizing yourself with the dashboard:

• Learn about creating Lifecycle Management policies

• Configure access profiles for your organization

• Set up integrations with identity sources

• Understand available Lifecycle Management actions

Overview

Access Profile Types determine the behavior of Access Profiles for Veza Lifecycle Management and Veza Access Requests. They define common characteristics such as:

• Whether the profile can inherit entitlements from other profiles

• If the profile can grant entitlements in one or more target applications

• The maximum number of entitlements the profile can grant

• The specific integrations where entitlements can be granted

Veza provides built-in profile types, such as Profiles and Business Roles, for hierarchical management of birthright entitlements by employee population. You can also create new profile types to meet your organization's Access Requests and Lifecycle Management needs.

Common Access Profile Type Categories

Access Profiles define collections of entitlements within one or more target applications that can be assigned to an identity. Depending on the profile type, an access profile can include certain groups or roles, or inherit entitlements from another profile.

For example, you can create different types to organize profiles by:

• Applications: Granting access to an application without specific entitlements, such as access to Zoom

• Single Entitlements: Defining a single entitlement within a single application, such as a user being added to the DNS Admin group in Active Directory or the Domain Name Administrator role in Entra ID

• Application Entitlements: Defining multiple entitlements within a single application, such as access to several Okta Groups

• Multi-Application Entitlements: Defining multiple entitlements across different applications, such as for site reliability engineers who need access to GitHub, AWS, Jira, and Snowflake, along with one or more roles and group memberships within each of those applications

• Business Roles: Inheriting combinations of other profile types to model sophisticated access privileges, such as all US Call Center employees inheriting US Employee access

Managing Access Profile Types

Use Access Profile Types to set rules for all profiles using that type. You can create new profile types to implement Lifecycle Management and Access Requests based on how and what access you will grant to employees.

Creating a New Profile Type

1. Open Lifecycle Management > Settings

2. In the Profile Types section, click New Profile Type

3. In the sidebar, configure the new type:

   • Basic Information shown when creating Access Profiles:

     • Name: Display name for the profile type, shown when creating new Access Profiles

     • Description: Extended description to document the purpose of the profile type

     • Instructions: Optional custom instructions for using the profile type, shown when creating new profiles. Note that this is useful if allowing self-service Access Profile creation.

   • On Create Behavior: Set the default policy state for Access Profiles created with this profile type:

     • Default: Uses Veza's default behavior (currently sets the profile to Initial state, but this may change in future releases)

     • Initial: The Access Profile is created but remains inactive/non-functional until a user explicitly starts it to move it to Running state

     • Running: The Access Profile starts in an active state and is immediately functional with no additional action required

     • Initial Start By Admin: The Access Profile starts in Initial state but requires an administrator (not a regular user) to explicitly start it to move it to Running state

   • Relationship Options:

     • Allow Inheritance from Other Access Profiles: When enabled, profiles with this type can use another access profile to specify the exact entitlements.

     • Allow Direct Relationships: When enabled, you will specify the exact entitlements when creating a profile with this type. When disabled, profiles with this type can only inherit entitlements from another profile

   • Access Request Policy: Choose the default Access Request Policy to apply access duration controls and approval workflow.

     • Allow overwrite of Access Request Policy: Enable selection of an alternative policy when Access Profile creators and owners create Access Profiles of this type.

   • Integrations: Choose if the Access Profile of this type supports multiple integrations, integrations of a single type, or a single instance of a single integration:

     • Allow multiple integration types: Profiles can have specific entitlements in more than one target integration type (such as one or more entitlements from any Active Directory or Okta integration)

     • Limit to a single integration type: Entitlements must be within integrations of a specific type (such as one or more entitlements from any Okta integration)

     • Limit to a single integration: Profiles are limited to a single integration (such as one or more entitlements from a specific Okta integration)

     • Create a local user account only (if limited to a single integration): Create a local user account without specific entitlements.

   • Entitlements: Set the maximum number of entitlements that can be added to profiles with this type (0 for unlimited entitlements).

     • Access Profile creators and owners can choose specific entitlements when editing the profile.

     • Create New Entitlement if None Exists: Configure the CREATE_ENTITLEMENT action to run when the policy is applied, including:

       • The target integration and entity type to create

       • Any member conditions (ANY to apply to all identities, or restricted by a condition string)

       • Attributes for the created entities using the specified formatters.

       • Enabling Continuous Sync to periodically recreate and reapply entitlements if removed within the target system.

4. Click Create Profile Type to save the changes

After saving a profile type, you can edit or delete it on the Lifecycle Management Settings > Profile Types tab.

• To manage the users or groups allowed to create profiles of that type, click Actions > Manage Permissions.

• To view profiles with a specific type, choose a profile type and click Show Access Profiles.

Best Practices for Access Profile Types

When working with Access Profile Types, consider the following best practices:

• Consistent Naming: Use clear, descriptive names for profile types that indicate their purpose and scope

• Appropriate Granularity: Create profile types with the right level of granularity for your organization's needs

• Documentation: Add thorough descriptions and instructions to help others understand when to use each profile type

• Inheritance Planning: Carefully plan which profile types should inherit from others to create a logical hierarchy

• Regular Review: Periodically review profile types to ensure they continue to meet your organization's needs

• Good Hygiene: Eliminate profile types that are no longer in use (when the count of Access Profiles with that type equals zero)

Overview

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 for more details.

Enabling Lifecycle Management for Coupa CCW

Prerequisites

1. You will need administrative access in Veza to configure the integration and Customer Integration Admin privileges in Coupa CCW.

2. Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.

3. Verify your Coupa CCW integration has completed at least one successful extraction

4. The Coupa CCW integration will need the required API scope:

   • ccw.contingent_workers - For accessing contingent worker data

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a Coupa CCW integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Coupa CCW data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Coupa CCW in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

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

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

Supported Actions

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 :

Source of Identity

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

• Manager relationships for approval workflows

Workflow Examples

Contingent Worker Onboarding

When a new contingent worker is added to Coupa CCW:

1. Identity Sync: Coupa CCW provides worker details to Veza Lifecycle Management

2. Access Provisioning: Based on department, cost center, and role, appropriate access is granted in target systems

3. Manager Assignment: Hiring manager relationships are established for approval workflows

4. Group Assignment: Worker is added to relevant organizational groups based on Account Segment and Department

Contingent Worker Status Changes

When a contingent worker's status changes (contract end, role change):

1. Status Detection: Coupa CCW reflects updated employment status

2. Access Review: Lifecycle policies evaluate continued access needs

3. De-provisioning: If terminated, appropriate access removal is triggered in target systems

4. Audit Trail: All changes are tracked for compliance reporting

Contract-to-Hire Conversion

When a contingent worker transitions to full-time employee:

1. Status Update: Employment type change is detected in Coupa CCW

2. Access Migration: Existing access is evaluated and potentially expanded

3. System Updates: Worker identity is updated across all connected systems

4. Process Completion: Manager and HR notifications confirm successful transition

Overview

System attributes are computed properties that Lifecycle Management automatically generates during identity processing. These attributes enable advanced automation scenarios by providing runtime information about identity changes and transformation results.

All system attributes follow the sys_attr__ prefix convention and cannot be manually set or modified.

Available System Attributes

sys_attr__is_mover

A persistent boolean attribute that indicates whether an identity has undergone changes to monitored properties.

Type: Boolean Persistence: Stored with identity record Available in: Workflow triggers, conditions, and transformers

Configuration: Define monitored properties in the policy configuration:

Workflow Trigger Example:

Combined Condition Example:

The attribute is automatically set to true when any property in mover_properties changes during identity update. It is cleared when the identity is unchanged in an extraction cycle, and excluded from change detection to prevent recursive updates.

System attribute names are case-sensitive and must be lowercase in all expressions.

sys_attr__would_be_value

A transient attribute that provides a preview of the transformation result during conditional evaluation.

Type: String Persistence: Transient (exists only during IF statement evaluation) Available in: Conditional transformers only

Usage Example - Conditional Domain Addition:

The above transformer will check if the transformed email already contains "@", preserve existing email addresses, and add domain only when needed.

sys_attr__would_be_value_len

A transient attribute that provides the character length of the transformation result during conditional evaluation.

Type: Number Persistence: Transient (exists only during IF statement evaluation) Available in: Conditional transformers only

Usage Example - Progressive Username Truncation:

For "Leonevenkataramanathan Foster":

• First check (≤30 chars): leonevenkataramanathan.foster (30 chars - passes first condition)

• If >30 chars, second check (≤20 chars): leonevenkataramana.foster (25 chars - fails second condition)

• If >20 chars, fallback: l.f (3 chars - always succeeds)

• Alternatives with NEXT_NUMBER: l.f2, l.f3, l.f4

Integration with NEXT_NUMBER

Preview attributes work with the NEXT_NUMBER transformer for generating unique alternatives:

This evaluates the base value length before applying numbering, ensuring the final result (including numbers) meets constraints.

Only one NEXT_NUMBER transformer is allowed per conditional branch.

Workflow Trigger Properties

The sys_attr__is_mover attribute supports additional trigger properties for fine-grained control:

This workflow triggers only when:

• The identity is marked as a mover (department or location changed)

• The identity is active

• At least one of the trigger_properties has changed since last extraction

Performance Notes

• Mover Detection: Comparison occurs for all properties in mover_properties during each extraction

• Preview Evaluation: Each IF branch with preview attributes requires transformation execution

• Optimization: Place most common conditions first to minimize preview evaluations

• Caching: Preview values are calculated once per condition branch and reused

See Also

• - Complete list of transformation functions

• - Attribute transformation concepts and examples

• - Configuring mover properties and workflows

Overview

Fallback formatters can help resolve conflicts when provisioning identities with unique attributes. This is particularly useful when automated provisioning requires unique identifiers, but the standard generated values are already in use.

Understanding Fallback Formatters

When provisioning new identities through Lifecycle Management, unique attributes like usernames, login IDs, or email addresses must not conflict with existing values. Fallback formatters provide an automated way to generate alternative values when conflicts arise, ensuring provisioning can proceed without manual intervention.

You can configure fallback formatters when configuring a Sync Identities Action to ensure new users can be onboarded efficiently, regardless of naming conflicts.

Use Case: Username Conflicts

The most common use case for fallback formatters is handling username conflicts. For example:

Your organization uses a standard username format of first initial + last name (e.g., jsmith for John Smith).

When multiple employees have similar names, this can lead to conflicts:

• John Smith already has jsmith

• Jane Smith already has jsmith1

• James Smith already has jsmith2

When Jennifer Smith joins, the fallback formatter automatically assigns jsmith3, maintaining your naming convention while ensuring uniqueness.

Configuring Fallback Formatters

Fallback formatters can be configured as part of the "Sync Identities" action within a Lifecycle Management workflow:

1. Edit or create a Lifecycle Management policy

2. Edit the workflow containing the Sync Identities action

3. In the Sync Identities action configuration, click Add Fallback

4. Configure the Transformer to use as a fallback pattern for the unique attribute that might experience conflicts

5. Close the action sidebar and save your changes to the policy.

Transformer Options for Fallback Formatters

Several transformers can be used for implementing fallback formatters depending on your specific use case.

Using the NEXT_NUMBER Transformer

A typical approach is to use the NEXT_NUMBER transformer, which is specifically designed to generate sequential numerical alternatives when naming conflicts occur.

The NEXT_NUMBER transformer:

• Generates a set of sequential integers as strings

• Takes two parameters: BeginInteger (starting number) and Length (how many numbers to generate)

• Is unique among transformers in that it returns multiple values, making it ideal for fallback scenarios

Other Useful Transformers for Fallbacks

In addition to NEXT_NUMBER, other transformers can be valuable for creating fallback formatters:

Using Random Alphanumeric for Unique Usernames:

{first_initial}{last_name}{RANDOM_ALPHANUMERIC_GENERATOR(4)}

This could generate usernames like jsmith8f3d instead of sequential jsmith1, jsmith2, etc.

Using UUID for Guaranteed Uniqueness:

{first_initial}{last_name}-{UUID_GENERATOR() | SUB_STRING,0,8}

This would append the first 8 characters of a UUID, creating identifiers like jsmith-a7f3e9c2.

Implementation Example

When configuring a fallback formatter with the NEXT_NUMBER transformer:

1. Select the attribute that requires uniqueness (e.g., username, email)

2. Configure the primary pattern (e.g., {first_initial}{last_name})

3. Add a fallback using the NEXT_NUMBER transformer to generate sequential alternatives:

{first_initial}{last_name}{NEXT_NUMBER(1, 10)}

This will generate up to 10 alternatives: jsmith1, jsmith2, ... jsmith10

Common Fallback Patterns

Here are some commonly used fallback patterns:

How Fallback Resolution Works

When Lifecycle Management attempts to provision a new identity with a unique attribute value that already exists:

1. The system first tries the primary format (e.g., jsmith)

2. If a conflict is detected, it automatically tries the first alternative using the NEXT_NUMBER transformer (e.g., jsmith1)

3. If that value also exists, it tries the next alternative (e.g., jsmith2)

4. This process continues until either:

   • A unique value is found

   • All alternatives from the NEXT_NUMBER range are exhausted (in which case an error would be reported)

This automated conflict resolution ensures provisioning can proceed without manual intervention, even when your standard naming conventions result in conflicts.

The Lifecycle Management Activity Log provides visibility into all provisioning operations performed by Veza's Lifecycle Management system. It serves as a record of all activities, including successful actions, errors, and failures.

Overview

A Lifecycle Management policy defines automated workflows that execute when changes occur in a source of identity. The Activity Log tracks all aspects of these operations through a hierarchical structure:

1. Policies define the overall automation framework for managing identities

2. Workflows determine which actions should be executed for specific identities

3. Actions represent specific operations to be performed on target systems

4. Jobs are individual tasks executed as part of actions

5. Events record atomic changes resulting from successful jobs

The Activity Log provides four views of this activity across different tabs: Events, Jobs, Actions, and Workflow Tasks.

Activity Log Tabs

Each tab can help track recent actions, verify that expected changes have occurred, identify patterns or issues in lifecycle events, and monitor the overall health of your Lifecycle Management implementation.

Events Tab

The Events tab shows individual changes made to entities and relationships within the system. Each event represents an atomic change resulting from a successful action.

Jobs Tab

The Jobs tab displays individual jobs executed as part of actions. Jobs represent specific tasks performed on target systems, such as creating a user account or updating attributes. Use this tab to review whether individual jobs executed successfully or encountered an error and could not be completed.

Actions Tab

The Actions tab shows high-level operations triggered by workflows. Actions typically involve one or more jobs that work together to accomplish a specific goal.

See for more details on supported actions and configuration options.

Workflow Tasks Tab

The Workflow Tasks tab displays workflows executed for specific identities. Workflows represent a sequence of actions executed as part of a Lifecycle Management .

Workflow Execution Process

For each identity, Lifecycle Management follows this process:

1. Validation: The system validates the identity against workflow trigger conditions

2. Execution Determination: The system determines whether execution is needed based on:

   • Identity state (e.g., CREATED, CHANGED, UNCHANGED)

   • Continuous sync settings

   • Last execution time (for unchanged identities)

3. Task Creation: If execution is needed, a workflow task is created

4. Action Execution: The system executes conditions and actions via the task runner

5. Result Storage: The result is stored as an event in the Activity Log

Using the Activity Log

The Activity Log provides filtering and search options to help locate particular events:

• Filter by time period: Use the date range filters to focus on date ranges

• Search by identity or entity: Use the search fields to find activities related to unique identities or entities

• Filter by event type or state: Use the dropdown filters to focus on event type or state

• View error messages: Review issues by checking for error messages in the Message column

Log Retention and Security

Veza maintains all Lifecycle Management activity logs for audit purposes. These logs are retained even if the associated integration is removed, maintaining a full historical record of all provisioning operations.

Note: Events shown in the Activity Log are distinct from the system-wide Event Logs found in the Veza Administration section.

Overview

Lifecycle Management policies define the workflows that are triggered when a user is added or other events are detected at a specific source of identity. This might include hiring a new employee, terminating an existing employee, or other status changes. Workflows contained in a policy describe conditional sequences of actions that can be structured based on the specific joiner, mover, leaver (JML) scenarios that you want to automate.

A policy can contain one or more workflows that run under different conditions. For example, one workflow might apply when employees enter an "Active" state (for Joiner/Re-hire scenarios), and another when an employee becomes "Inactive" (for Leaver scenarios). A workflow could also trigger when an employee hire date is within a certain threshold, such as less than 4 days away, or relative to any other employee property within the source of identity.

For most enterprise deployments, Veza recommends:

• One policy for each source of identity integrated with Lifecycle Management

• Two workflows within each policy:

  • One for active users to cover Joiner and/or Mover scenarios (including Re-hire)

  • Another for inactive users to cover Leaver scenarios

Add a Lifecycle Management Policy

To create a policy for a source of identity:

1. Go to Lifecycle Management > Policies

2. Click Create Policy

3. Give the policy a name and description

   • The policy name is used to identify it on the Policies list and appears in event logs

   • The name should indicate the source of identity the policy applies to

4. Choose the Data Sources the policy will apply to

   • Use the dropdown menu to select the source of identity that will trigger workflows in the policy

   • To appear on this list, the integration must have Lifecycle Management enabled and be available as a source of identity

   • See Integrations for supported providers and steps to enable a Lifecycle Management data source

5. Save the policy

Edit a Lifecycle Management Policy

To edit a policy:

1. Go to Lifecycle Management > Policies

2. Choose a policy from the list and click Edit

3. Configure the policy summary, details, and identity source.

4. Click on a tab in the policy builder to configure its settings:

   • Workflows: Configure the actions that trigger when there are changes in a source of identity

   • Common Transformers: Define shared rules for creating or updating target attributes when provisioning, syncing, or de-provisioning identities

   • Notifications: Configure email notifications or webhooks for the policy's workflows, with different notification rules for different types of events (e.g., "Create Identity" or "Delete Identity")

5. Save the policy

Enabling and Monitoring Lifecycle Management Policies

Use the Policies page for an overview of initial, running, and paused Policies. New policies are created in the "Initial" state, enabling a review period before activating the policy. Active ("Running") policies will apply the next time the data source is extracted.

To manage policies on the main Policies overview:

1. Go to Lifecycle Management > Policies

2. Find the policy you want to manage

   • Search for a specific policy by name

   • Filter to show all providers by their current state

3. Click the ⋮ icon in the rightmost column to expand the Actions menu

4. Choose to Edit, Pause, View Details, or Delete the policy

Adding Workflows to Policies

Policies contain one or more workflows that typically correspond to Active and Inactive user states. Workflows define a sequence of actions to run when a condition is met, based on events and user changes captured at the source of identity. These workflows apply to scenarios such as new employee hiring, department changes, or employee departures.

Workflows contain a tree-like sequence of conditions to meet specific requirements of your joiner, mover, and leaver processes. For example, you may want to grant specific entitlements to users with specific roles, locations, or groups.

Workflows can trigger:

• As soon as an identity is detected with a matching attribute

• Relative to an attribute containing a date (such as before or after a hire_date or termination_date)

• Based on any attribute available from the source of identity

Create a Workflow in a Policy

To add a workflow to a policy:

1. Edit a policy and open the Workflows tab

2. Click Add Workflow to open the sidebar for adding details and conditions

3. Use the General tab to configure workflow settings:

   Workflow Details:

   • Name and Description: Identify the workflow's purpose

   • Continuous Sync: Enable to update target entities when source identity changes occur

   Condition:

   • Workflow Condition: Specify the trigger attribute and value

   • Supports SCIM query syntax for filter expressions

   • Examples:

     • employment_status eq "WITHDRAWN" for terminated employees

     • employment_status eq "ACTIVE" for new hires and movers

   Workflow Trigger Details:

   • Attribute to Get Execute Date: Specify when workflow actions should run

   • Local Time Zone Diff From UTC: Set your UTC offset

     • Eastern Standard Time (EST): -5

     • Pacific Standard Time (PST): -8

     • Note: US UTC offset varies during Daylight Savings Time

   • Trigger At Local Time Hour: Set execution time in 1-hour intervals (e.g., 6, 12, 24)

4. Use the Conditions tab to configure action sequences:

   a. Click Add Condition to configure settings:

   • Condition Name: Use descriptive names (e.g., "Sync Okta Identities" or "Azure Helpdesk Role")

   • Continue Actions if Any Error: Enable to continue workflow despite failures

   • Condition Type: Choose between immediate execution or SCIM filter-based conditions

   b. Configure Actions:

   • Choose Action Type:

     • New: Create an action with custom settings

     • Existing: Select a previously created action

   • Use Edit Action > Conditions for nested conditions

   c. Add additional conditions as needed

5. Save changes:

   • Click Save in the left sidebar for workflow changes

   • Click Save on the policy details page to commit all changes

Common Transformers

Common transformers define one or more rules to apply when synchronizing a target identity's attributes. Use them in situations where you want to create or update attributes using the same conventions across multiple sync or de-de-provision actions.

To add a common transformer:

1. Edit a policy and open the Common Transformers tab

2. Give the transformer a name and description, and specify the data source it applies to.

3. Choose the target Entity Type.

4. Click Add Attribute to specify an attribute and the value format.

5. Optionally, enable Continuous Sync to keep the target entity up-to-date with values from the source of truth.

6. Save the transformer.

See Transformers for available transformation functions.

Notifications

Events and Actions

Events and Actions: Lifecycle Management Actions can result in multiple events, each associated with a specific operation in a target application. An action might cause more than one event. For example, the "De-provision Identity" action for Active Directory leaver flows could result in a combination of events:

• "Disable Identity" (set account to inactive)

• "Sync Identity" (update DN and primary group DN)

• "Remove Relationship" (remove existing profiles) events. You can review individual events and their status using the Activity Log.

Monitor individual events and their status using the Activity Log.

Notification Configuration

When events occur during the execution of a policy’s workflow, notifications can be triggered by Lifecycle Management as a means to inform stakeholders or integrate with external systems, such as triggering external automation. These notifications are configured in policies and Lifecycle Management supports email- and webhook-based notifications.

Use the Notifications tab when editing a policy to add and manage notifications at the policy level:

1. Choose the notification type (Email or Webhook)

2. Choose the event to trigger notifications:

   • Create Identity

   • Sync Identity

   • Add Relationship

   • Remove Relationship

   • Create Email

   • Change Password

   • Delete Identity

   • Disable Identity

   • Manage Relationships

   • Write Back Email

3. Choose the status to trigger notifications (when an event is successful, or it fails).

4. Customize the email or webhook settings:

   • Webhook:

     • Webhook URL: The endpoint configured to receive the webhook payload.

     • Webhook Auth Header: if the webhook listener requires authentication, provide it here.

   • Email:

     • Emails: Recipients added to the to field.

     • Extra Email Fields (Optional): Recipients added to the cc field.

5. Save the changes.

Note that emails and webhooks can also be configured on a per-action basis.

This guide describes how to enable and configure Exchange Server for Lifecycle Management in Veza, including supported capabilities and configuration steps.

Supported Capabilities

Lifecycle Actions Supported

Create Email

Supports the creation of email accounts for users within Exchange Server.

• Entity Type: Exchange Server Users

• Attributes Available for Configuration:

  • Identity (Required)

  • Alias (Optional)

Example Use Cases:

• Create email accounts for new employees joining the organization

• Assign email aliases to users to facilitate communication

Configuration Steps

1. Locate Exchange Management Shell Paths

1. Find the Exchange Management Shell shortcut in the Start Menu

2. Right-click > More > Open File Location
3. Right-click the shortcut icon > Properties
4. Copy the Target field value
5. 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)

2. Create Application Pool in IIS

1. Open IIS Manager and create a new application pool
2. Name the application pool
3. Configure the application pool:

   • Right-click > Advanced Settings

   • Under Process Model, set the Identity

3. Configure IIS Application

1. Add the application to "Default Web Site"
2. Configure the application:

   • Set alias to "VezaProvisioner"

   • Select the application pool created above
3. Configure authentication:

   • Disable Anonymous Authentication

   • Enable Basic Authentication

4. Install Veza Provisioner

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.

5. Configure Exchange Server Integration in Veza

1. Go to Configurations > Integrations

2. Click Add New and select Exchange Server

3. Complete the following fields:

   Field

   Description

   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

4. Enable Lifecycle Management by checking Enable Lifecycle Management

5. Save the configuration

6. Verify Configuration

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.

Overview

This guide explains how to configure identity override attributes in Lifecycle Management to address scenarios where user attributes at the source of identity are incorrect, slow to update, or temporarily need adjustment for policy execution.

Identity override attributes allow Lifecycle Management administrators to override the value of any user attribute set at the source of identity. These overrides take precedence over actual values during Lifecycle Management workflows.

Problem scenarios for attribute overrides

Identity override attributes address operational challenges where the source of identity doesn't immediately reflect ground truth:

• Incorrect or slow-to-update attributes:

  • Employee termination: An employee has been terminated and needs immediate deprovisioning, but the termination status is not yet reflected at the source of identity

  • Role changes: An employee has immediately changed roles and needs new birthright access, but the role change and the new manager haven't been updated in the source system

  • Contract extensions: A contractor's end date has been extended, but the extension isn't reflected yet at the source of identity

  • Missing manager data: The source of identity is missing a manager value, but this information is required for downstream application provisioning

• Emergency access control:

  • Security incidents: Immediate access restrictions are needed before HR systems can be updated

  • Temporary access grants: Providing temporary access while permanent changes are processed

Before you start

Before you configure identity override attributes, verify that override values comply with organizational policies and data standards, and assess the downstream impact of attribute changes. Ensure:

• You have administrative access to Veza Lifecycle Management

• You understand which source identity attributes need to be overridden

• You have identified the specific identities requiring attribute overrides

• You understand that overrides only affect Lifecycle Management workflows, not Access Visibility

• You recognize that overrides should be used for exceptional cases, not routine operations

Configure identity override attributes

Veza supports overrides for various property types from the source of identity:

• Text properties (e.g., Department, Manager, Job Title)

• Date properties (e.g., Activated At, Hire Date, End Date)

• Numeric properties (e.g., Employee ID)

• Boolean properties (e.g., Active status, Enabled flags)

Create attribute overrides for individual identities

You can view, create, edit, and delete overrides from the identity details view.

1. Click Lifecycle Management in the main navigation, then select the Identities tab.

2. Locate the identity requiring an attribute override.

   2.1. Use the Search by name field to find the specific user

   2.2. Click on the identity name to show more information in the sidebar

   2.3 Click Details to open the expanded details view

3. Open the identity's Properties tab:

   3.1 In the identity detail view, click the Properties tab to view all available attributes from the source of identity.

   The Properties tab displays both original attribute values and any existing overrides.

4. Create a new attribute override:

   4.1. Find the attribute you want to override in the properties table

   4.2. Click the Actions menu (three dots) for that attribute

   4.3. Select Create Override from the dropdown menu

5. Set the override value in the Create Override dialog:

   5.1. Enter the desired override value in the Override Value field

   5.2. For date attributes, use the calendar picker to select the appropriate date and time

   5.3. For text attributes, type the new value directly

   5.5. Click Save to apply the override, or Cancel to discard changes

   The Create Override modal displays the attribute name and the current actual value for reference.

6. Verify the attribute override is active:

   • The Override column now shows "yes" for the modified attribute

   • The Override Value column displays your custom value

   • The override count updates in the Property Overrides filter (e.g., "1 Override")

7. View the override summary in the identity details Overview tab:

   7.1. Return to the Overview tab for the identity

   7.2. Check the Property Overrides section to see all configured overrides for the identity

   7.3. Each override displays the attribute name, override value, and actual value from the source

The identity details view provides visibility into both original and overridden values. A visual indicator will highlight any attributes with overrides:

1. Properties: Use this tab to show side-by-side comparisons of actual values from the source of identity and override values

2. Overview: This tab includes a consolidated view of all active overrides for an identity

Update existing overrides

To change the value of an attribute override:

1. Navigate to the identity's Properties tab. Access the same identity detail view where you created the override.

2. Locate the attribute with an active override. Find the attribute showing "yes" in the Override column.

3. Edit the override value.

   3.1. Click the Actions menu (three dots) for the overridden attribute

   3.2. Select Edit Override from the dropdown menu

3.3. Modify the Override Value in the dialog 3.4. Click Save to apply the changes

Cancel attribute value overrides

To remove an override:

1. Access the identity's Properties tab. Navigate to the identity detail view with active overrides.

2. Identify the override to remove. Locate the attribute with "yes" in the Override column.

3. Clear the override.

   3.1. Click the Actions menu (three dots) for the overridden attribute

   3.2. Select Clear Override from the dropdown menu

   3.3. Confirm the action when prompted

The attribute will revert to using the source of identity value, and the Override column will show "no".

Important considerations

Override scope and limitations

The current implementation supports overrides at the individual identity level. Note that any attribute overrides are not reflected in the Veza Access Graph.

• Lifecycle Management only: Attribute overrides affect only Lifecycle Management workflows and policy execution

• Access Visibility unchanged: The authorization graph and Access Visibility features continue to use the actual source of identity values

• Source system independence: Overrides do not modify data in the originating identity providers or HR systems

Operational best practices

You should typically use overrides as temporary measures while addressing root causes in source systems. Maintain clear records of why each override was implemented and the business justification.

Consider the following best practices when implementing attribute overrides:

• Regular review process: Establish periodic audits of active overrides to ensure they're still necessary

• Monitor policy impact: Review workflow execution logs to confirm that overrides produce expected policy outcomes. You can review the identity details Activity tab and Lifecycle Management Activity Logs to ensure that override values are applied as expected during provisioning, deprovisioning, and other lifecycle actions.

• Emergency response procedures: Establish clear protocols for when and how to use overrides in approved scenarios.

• Change management coordination: Communicate with HR and identity provider teams when overrides are needed.

See also

This guide describes how to enable and configure Active Directory for Lifecycle Management in Veza, including supported capabilities and required configuration steps.

Overview

Active Directory integration with Lifecycle Management enables automated user provisioning, access management, and de-provisioning capabilities. This includes creating and managing AD users, group memberships, and disabling accounts when employees leave the organization.

Supported Capabilities

Identity Provider Status

Active Directory serves as an Identity Provider in Lifecycle Management workflows and supports custom properties defined in the integration configuration.

Supported Actions

Manage Relationships

Controls relationships between users and Active Directory groups.

• Entity Types: Active Directory Groups

• Assignee Types: Active Directory Users

• Supports Removing Relationships: Yes

Example Use Cases:

• Add users to specific Active Directory groups to manage access

• Remove users from groups when access requirements change

Sync Identities

Synchronizes identity attributes between Active Directory and downstream systems.

• Create Allowed: Yes (New user identities can be created if not found)

• Supported Attributes:

  • Required (Unique Identifiers):

    • AccountName (No Continuous Sync)

    • DistinguishedName

    • UserPrincipalName

  • Optional:

    • Email, GivenName, DisplayName, SurName, Title

    • Description, ManagerID, PrimaryGroupDN

    • StreetAddress, City, StateOrProvinceName

    • CountryCode, PostalCode, Company

    • PhysicalDeliveryOfficeName, JobTitle

    • Department, CountryOrRegion, Office

Example Use Cases:

• Create new user accounts when users are added

• Keep user information synchronized across integrated systems

De-provision Identity

Safely removes or disables access when users leave or no longer need access.

• Entity Type: Active Directory Users

• Remove All Relationships: Yes (Removes existing group memberships)

• De-provisioning Method: Disabled (Users are marked as disabled rather than deleted)

Example Use Cases:

• Disable accounts when employees leave

• Remove group memberships while retaining audit information

Configuration Steps

1. Create a Service Account

Create a dedicated AD user with minimum required permissions:

Using Active Directory Users and Computers:

1. Open Active Directory Users and Computers

2. Navigate to the target Organizational Unit

3. Right-click > New > User

4. 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:

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 $True

2. Configure Required Permissions

Grant the service account permissions to manage users in the target OUs:

Using Active Directory Users and Computers:

1. Navigate to the target Organizational Unit

2. Right-click > Delegate Control

3. Click Add and enter the service account name

4. Select these delegated tasks:

   • Create, delete, and manage user accounts

   • Reset user passwords and force password change

   • Read all user information

   • Modify group membership

Using PowerShell:

Import-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 $ACL

3. Configure the Integration in Veza

1. Navigate to Configurations > Integrations

2. Either:

   • Create a new Active Directory integration

   • Edit an existing Active Directory integration

3. Enable Lifecycle Management:

   • Check Enable Lifecycle Management

   • Enter the Lifecycle Management Username (service account created above)

   • Enter the Lifecycle Management Password

4. Save the configuration

Note: 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 required permissions listed above.

This guide describes how to enable and configure Workday for Lifecycle Management in Veza, including supported capabilities and configuration steps.

Overview

Workday integration enables automated Lifecycle Management workflows using Workday as a source of truth for employee identity information, including:

• Automated security group assignments for new employees

• Dynamic group membership updates during role changes

• Access removal during offboarding

• Email synchronization between Workday and downstream systems

Supported Capabilities

Source of Identity

Workday serves as an authoritative source for employee identity information:

• Entity Type: Workday Worker

• Purpose: Used as the source of truth to trigger lifecycle management workflows based on worker record changes

Lifecycle Actions

Manage Relationships

Controls access to Workday security groups.

• Entity Types: Workday Security Group

• Assignee Types: Workday Account

• Supports Relationship Removal: Yes

Write Back Email

Updates email addresses in Workday worker records to maintain consistency with other systems.

• Entity Type: Workday Worker

• Purpose: Ensures Workday remains the single source of truth for employee email addresses

Custom Properties

The integration supports custom attributes defined in your Workday configuration, which can be used in lifecycle management conditions and transformers.

Configuration Steps

1. Create Business Process Security Policy

1. Log into Workday and search for Edit Business process security policy

2. Under Business Process Type, select Work Contact Change
3. Find "Initiating Action: Change Work Contact Information (REST Service)"

4. Create a Segment-Based Security Group
5. Configure the security group:

   • Add the security group created for Veza integration

   • Add "Worker" scope to Access Rights
6. Verify the security group appears in Initiating Action Security groups
7. Click OK and Done to save changes

2. Activate Security Policy Changes

1. Search for Activate Pending Security Policy Changes

2. Review changes, add a comment, and click OK
3. 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

1. Open Edit API Client

2. Add required scopes:

   • Staffing

   • Contact Information

   • System

   • Tenant Non-Configurable

   • Organizations and Roles

5. Configure Workday Integration in Veza

1. Navigate to Configurations > Integrations

2. Either:

   • Create a new Workday integration

   • Edit an existing Workday integration

3. Enable Lifecycle Management:

   • Check Enable Lifecycle Management

4. If using custom attributes, configure them in the Custom Properties section

API Access Notes

The integration uses these API endpoints for email write-back:

%s/ccx/api/person/v3/%s/workContactInformationChanges/%s/emailAddresses
%s/ccx/api/person/v3/%s/workContactInformationChanges/%s/submit
%s/ccx/api/staffing/v5/%s/workers/%s/workContactInformationChanges

For general metadata discovery, WQL queries access:

• allWorkdayAccounts

• allWorkers

• securityGroups

• domainSecurityPolicies

• businessProcessTypes

Implementation Notes

1. Workday Workers are the primary entity for identity information

2. Bidirectional management of Account-Security Group relationships is supported

3. Email write-back operates on Worker entities, not Account entities

4. Custom attribute availability depends on your Workday configuration

5. The Sync Identities action is not currently supported for Workday

Access Profiles govern how application entitlements are assigned to employees across your organization. These profiles define how birthright access should be granted based on segmentation criteria, which could include business role, job function, seniority level, location, or group membership. Access Profiles are used by the Manage Relationship action to assign users to specific groups, roles, permission sets, or other access-granting entities when specific conditions are met.

Profiles can be configured hierarchically to create a fine-grained model of how access should be assigned to different groups of employees. Administrators can position child profiles underneath a parent profile, with each child profile inheriting the entitlements from the parent profile.

For instance, a parent profile might be "Sales" (defining all the application entitlements that an individual belonging to the Sales organization should be granted), with child Profiles for "Account Executive," "Sales Engineering," "Sales Operations," and "Inside Sales." Each child Profile will have additional application entitlements specific to those roles. With these profiles configured, a workflow in policy for sales engineers can use just the "Sales Engineering" Profile, which includes the access defined by the "Sales" profile.

Example Profiles

Since workflows in Lifecycle Management policies can apply these Profiles at all stages in a user's lifecycle, defining Profiles enables Veza to serve as a source of truth for birthright entitlements for all employees. Access Profiles also define what access-granting relationships to remove from users during de-provisioning workflows.

The access granted by a Profile can be defined by both:

• Explicitly-defined, application-specific entitlements, such as roles, groups, permission sets, etc., within the Profile. A single Access Profile can support granting one or more entitlements across one or more applications simultaneously.

• Any entitlements inherited from a parent Profile.

The example below shows Business Roles for teams, managers, and all employees, along with Profiles for different applications. When configuring workflow actions, administrators can choose from one or more Business Profiles to assign the entitlements granted by the child Profiles.

Access Profile Types

Veza offers two types of built-in Access Profile types for defining birthright entitlements by user segments:

Profiles

Profiles are a type of Access Profile for defining access-granting relationships (such as user assignments to groups or roles) within the applications you will provision to users. Profiles are intended to represent a specific set of entitlements across one or more applications that should be granted based on a user's segmentation criteria.

Profiles should be configured in coordination with the application owner, who will best understand the exact permissions and privileges granted by various groups, roles, and other entitlements in each specific application.

Business Roles

Business roles are a type of Access Profile used to model your organization's structure, based on a hierarchy of job functions, locations, and titles. Ideally by itself, a Business Role should not describe specific entitlements but can inherit relationships from other Profiles. These will usually be named according to logical segments that should be assigned to different applications with different levels of access, such as "Sales," "QA Contractors," or "Engineering Managers."

Best Practices for Access Profile Types

Business Roles can inherit Profiles to enable a hierarchical approach to birthright access management. You should draft and review Access Profiles to create a map of user entitlements for each application (such as "GitHub Developers" or "Salesforce Administrators").

Create Business Roles that align with your organizational structure, especially taking location, business unit, and functional organization into consideration. Then, configure these Business Roles to inherit Profiles that describe the birthright entitlements granted to different user populations.

Configuring Access Profiles

To create and manage Access Profiles, go to Lifecycle Management > Access Profiles.

1. Click Create Access Profile

2. Under Access Profile Details, choose the Profile Type to create:

   1. Business Role: Business roles are intended to represent logical units within your organizational structure, and can inherit entitlements defined in other Access Profiles. Use Business Roles to establish segmentation criteria based on location, role, business unit, or functional organization.

   2. Profile: Profiles define entitlements that can be assigned to users in target applications, such as groups, roles, or permission sets assigned to users as birthright entitlements. Profiles cannot be inherited from other Access Profiles, but can be inherited by Business Roles. Use this profile type to define the birthright entitlements within one or more applications (such as group memberships or role assignments).

3. Profile Name and Description: You should follow a standard naming convention for all profiles to help identify them, describing the employee segment or applications the Access Profile applies to.

4. Profile Labels: Labels are available for quickly finding access profiles when configuring actions in a policy. Apply and create labels as needed to organize your Access Profiles by the employee segments and applications they apply to.

5. Assigned Relationships:

   1. Click Add Relationship

   2. Choose the type of relationship to add:

      • Access Profile: Use the Relationship menu to pick one or more Access Profiles to grant those business roles or entitlements. This option is not available for Access Profiles with the "Profile" type.

      • Relationship: Choose the target data source and specific entities the Profile will govern access to (such as Google Cloud Platform > Google Group). This option is not available for Access Profiles with the "Business Role" type.

6. Click Assign to save the changes.

After saving an Access Profile, you can view details, edit, or pause and resume it on the Lifecycle Management > Access Profiles page.

When configuring a policy to include the Manage Relationships action, you can choose from any active profiles for the target data source.

See Also

• Manage Relationships

• Lifecycle Management Policies

Overview

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.

Enabling Lifecycle Management for GitHub

Prerequisites

1. You will need administrative access in Veza to configure the integration and site administrator privileges in GitHub Enterprise Server.

2. Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.

3. Verify your GitHub integration has completed at least one successful extraction

4. The GitHub integration will need the additional required GitHub App permissions:

   • 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

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.

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a GitHub integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your GitHub data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for GitHub in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

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

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

Supported Actions

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 :

Sync Identities

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

• Requires site administrator privileges for user creation operations

The following attributes can be synchronized:

Manage Relationships

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

• Track membership changes for audit purposes

Deprovision Identity

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

• Account can be reactivated if needed (unsuspended)

• User receives appropriate error messages when attempting to access GitHub

Workflow Examples

New Employee Onboarding

Create GitHub accounts and assign appropriate access for new developers:

1. Identity Sync: Create user account with basic profile information

2. Organization Access: Add user to primary GitHub organization

3. Team Assignment: Assign to development teams based on department

4. Profile Setup: Configure public email and display name

Role Change Management

Update GitHub access when employees change departments or roles:

1. Relationship Updates: Remove existing team memberships

2. New Access: Add memberships for new role requirements

3. Audit Trail: Track all membership changes for compliance

Employee Offboarding

Securely remove access while preserving development history:

1. Account Suspension: Suspend GitHub account to prevent access

2. Membership Removal: Remove all organization and team memberships

3. History Preservation: Maintain commit attribution and repository history

4. Compliance: Generate audit trail of all access removal actions

Overview

You can use Lookup transformers to convert identity attributes from a source system into appropriate values for target systems based on CSV reference tables. This is particularly useful when mapping values between systems that use different naming conventions, codes, or formats for the same conceptual data.

For example, you might need to transform a "Location" attribute from Workday (which might be stored as location codes like "MN001") into corresponding values for country, country code, or city names in a target system.

Use Table Lookup Transformers when:

• You need to map source attribute values to different values in target systems

• You have standardized reference data that must be consistent across applications

• You need to extract different pieces of information from a single attribute value

• You have complex mapping requirements that built-in transformers cannot support

Examples

1. Geographic Information:

   • Transform location codes to country, region, city, or timezone information

   • Map office codes to physical addresses or facility types

2. Organizational Mapping:

   • Convert department codes to department names or business units

   • Map cost centers to budget codes or accounting categories

3. System-Specific Configurations:

   • Transform job titles to role designations in target systems

   • Convert skill codes to certification requirements or training needs

How It Works

The Table Lookup Transformer references CSV-based mappings between source and destination values. When synchronizing user attributes, Veza:

1. Takes the source attribute value

2. Looks up this value in the specified lookup table

3. Returns the corresponding value from the designated return column

4. Applies this value to the target attribute

Lookup Table Structure

Lookup tables are CSV files with columns that map values from a source of identity to destination values. Each row represents a mapping entry. The first row must contain the column headers.

For example, a location mapping table might look like:

Creating and Managing Lookup Tables

Creating a Lookup Table

To create a new lookup table:

1. Navigate to the Lookup Tables tab within your policy configuration

2. Click Edit mode to enable policy changes

3. Click Add New to create a new lookup table

4. Provide a Name and optional Description for the lookup table

5. Drag a CSV file or click Browse to upload your reference data

6. Review the automatically detected column names

7. Click Save to store the lookup table

Managing Lookup Tables

From the Lookup Tables tab, you can:

• Edit table descriptions or upload a new CSV

• Delete tables that are no longer needed

Using Table Lookup Transformers

Basic Syntax

To use a Table Lookup Transformer in a common or action-synced attribute:

1. In Destination Attribute, choose the attribute on the target entity that will be updated

2. In Formatter, choose the source attribute to transform

3. In Pipeline Functions, specify the lookup table name, the column to match against, and the column containing values to return.

The full syntax for using lookup table transformers is:

Where:

• <value> is the source attribute to transform (e.g., {location})

• <table_name> is the name of the lookup table to use

• <column_name> is the column in the table to match against

• <return_column_name> is the column containing the value to return

Examples

Assuming a user has "location": "IL001" and a lookup table named locationTable structured as shown earlier:

Advanced Features

Pipeline Transformations

You can combine lookup transformations with other transformation functions in a pipeline:

This would look up the state_code corresponding to the location value and convert it to lowercase.

Handling Missing Values

When a lookup value is not found in the table, the transformation will fail for that specific attribute.

For full coverage, ensure your lookup table includes entries for all possible source values that may be encountered during provisioning.

To ensure robust provisioning workflows, it's important to include all expected values in your lookup table, validate source data before implementing lookup transformations, and test transformations with representative data sets.

Technical Details

Implementation Notes

• Lookup tables are immutable and automatically deleted when no longer referenced by any policy version

• Multiple policy versions can reference the same lookup table (e.g., an active version and a draft version)

• Lookup tables are defined at the policy level and can be referenced by any transformer within the policy

• Lookup tables can have multiple columns to support different transformations from the same reference data

Best Practices

1. Standardize Naming: To use a lookup-based transformer, you will reference the table by file name. Apply consistent conventions for both the table and columns.

2. Document Mappings: Add descriptions for each lookup table to explain its purpose

3. Validate Data: Ensure lookup tables are complete and accurate before using them in transformers. Consider how lookup tables will be maintained over time, especially for values expected to change.

Troubleshooting

Common Issues

Related Topics

Overview

The Veza integration for Snowflake enables automated user lifecycle management, with support for user provisioning and de-provisioning, role assignment management, and attribute synchronization.

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.

Enabling Lifecycle Management for Snowflake

Prerequisites

1. You will need administrative access in Veza to configure the integration and USERADMIN role or equivalent privileges in Snowflake.

2. Ensure you have an existing Snowflake integration in Veza or add a new one for use with Lifecycle Management.

3. Verify your Snowflake integration has completed at least one successful extraction

4. The Snowflake integration will need the additional required privileges:

   • CREATE USER privilege on the account for user provisioning

   • GRANT ROLE privilege for role assignments

   • OWNERSHIP privilege on target roles for role management

   • Access to a warehouse for executing queries during lifecycle operations

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.

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a Snowflake integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your Snowflake data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for Snowflake in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

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

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

Supported Actions

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:

Sync Identities

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:

Manage Relationships

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

Deprovision Identity

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

Workflow Examples

Employee Onboarding

Automated provisioning when a new employee joins:

1. Create User Account: Sync identity attributes from HR system to create Snowflake user with name and login details

2. Assign Department Role: Grant role based on department attribute (e.g., SALES_ANALYST, DATA_ENGINEER)

3. Set Default Role: Configure default role for the user's session

4. Add Email and Comments: Populate user profile with contact information and descriptive notes

Role Change Management

Managing access when employees change roles:

1. Update User Attributes: Sync changed attributes like email or comments

2. Remove Old Roles: Revoke previous role assignments that are no longer appropriate

3. Grant New Roles: Assign roles appropriate for the new position

4. Update Default Role: Change the user's default role for new sessions

Employee Offboarding

Secure access removal when employees leave:

1. Disable Account: Set user account to disabled status

2. Revoke All Roles: Remove all role assignments to eliminate data access

3. Preserve Audit Trail: Maintain user record and history for compliance

4. Optional Cleanup: Remove user completely with DROP USER if no audit trail is needed

Identities

Identities in Veza Lifecycle Management represent a top-level view of an individual user, used to automate provisioning and deprovisioning across systems, applications, or services.

This can include birthright access managed throughout the user's lifecycle, triggered by joiner, mover, or leaver events, as well as ad-hoc, just-in-time access granted upon approval of an access request.

Identities can refer to users who may be employees, contractors, or external collaborators (partners), but generally exclude non-human entities, such as service accounts or AI agents.

With Lifecycle Management, workflows defined within policies dictate the users’ onboarding, job-function change, and offboarding processes, ensuring that corresponding identities have precisely the access they need as their roles evolve or their status within the organization changes. Similarly, access granted to identities may also change as just-in-time access requests are fulfilled or revoked.

The Lifecycle Management > Identities page serves as a central hub for viewing identities known to Lifecycle Management and Access Requests, as well as performing actions on individual identities.

Identities are populated into Lifecycle Management by first identifying the entire user population by integrating their source of identity (SOI) and creating a policy that uses that data source, into a Veza tenant. This may require enabling a built-in integration for your identity source (e.g., Workday integration), uploading user data in CSV format (CSV Upload integration), or using a custom OAA connector.

See Integrations for detailed information on integrating the source of identity.

For Integration management using APIs, see the Datasource Management APIs.

Identity Synchronization

Identities are maintained through synchronization with the identity sources. Syncing identities ensures that all systems reflect the most current user state, whether through onboarding, role changes, or attribute updates, keeping access aligned, consistent, and audit-ready.

The Sync Identities action is used for the automatic synchronization of user identities between an authoritative source (such as an HR system or identity provider) and target systems. In the Lifecycle Management workflow, Sync Identities works alongside other key actions:

• Manage Relationships (handling group/role memberships)

• Deprovision Identity (removing access when users leave the organization)

Synchronization is executed through Lifecycle Management policy workflows. Policy workflows can be defined with triggers and actions to synchronize changes in your identity source with target systems. Additionally, SCIM (System for Cross-domain Identity Management) or OAA (Open Authorization API) can enable identity sync for a wide range of target applications that don't have a built-in Veza integration, but do expose standard user and group management APIs or support bulk data export.

• See SCIM for more information on usage.

• See Open Authorization API (OAA) for detailed information.

Identities Table

Note: The display name is not the primary unique identifier, as multiple users may share the same first and last name.

Filter and Search an Identity

To start, you can use filtering options to locate specific identities or analyze a group of identities based on standard criteria. The following filters are available on the Identities overview:

• Search by name: Locate specific individuals using a name-based search

• Department filter: View identities by organizational unit

• Status filter: Filter by Active or Inactive employment status

• Access Profiles filter: Find identities with specific profile assignments

• Integrations filter: Filter by source integration system

• Policy filter: View identities managed by specific policies

• Workflows Triggered filter: Identify identities that have triggered automation

• Not in a Workflow: Find identities outside automated workflows

Identity Actions

For each identity record, administrators can perform actions through the Actions menu:

• View Details: Access identity information, attribute history, and related accounts

• Trigger Workflow: Manually initiate a workflow in a policy

• Request Access: Launch an Access Request for additional access (requires Veza Access Requests).

  See Notification Templates for Lifecycle Management for customizing the Request Access Template.

• Show in Graph: Visualize identity relationships and access patterns

View User Details

Click on your selected identity to open the Identity Details view.

The following fields in the Identity Details view are populated with the current user's information:

• Title: The user’s position title.

• Email: The user’s email address.

• Providers: A list of assigned integrations. When you click on a specific provider, the Integration page appears, displaying the provider’s detailed information, including its Entity Categories distribution.

• Access Profiles: A list of assigned Access Profiles to the identity. When you click on a specific profile, its detailed information page appears, displaying its status (either Draft or Published). You can also edit the Access Profile if needed.

• Last Workflow Triggered: The name of the workflow that was recently executed.

• Primary: The Primary identifier is configured (True or False) to be the authoritative attribute for matching or locating an identity.

• Secondary Identities: An associated name is connected to the primary identity.

• ID: The Identification number assigned to the primary identity.

• Active: The user’s identity is active if True. Otherwise, False when inactive.

• Last Changed: A time frame (in days, weeks, months) when the identity was last changed.

Attribute Overrides

When executing a policy where user attributes at the source of identity are incorrect, slow to update, or temporarily need adjustment, you can override the existing attribute with a different value until the issue is corrected. For more information, see Identity Override Attributes.

Here are some examples of incorrect or slow-to-update attributes:

• Employee termination: An employee has been terminated and needs immediate deprovisioning, but the termination status is not yet reflected at the source of identity

• Role changes: An employee has immediately changed roles and needs new birthright access, but the role change and the new manager haven't been updated in the source system

• Contract extensions: A contractor's end date has been extended, but the extension isn't reflected yet at the source of identity

• Missing manager data: The source of identity is missing a manager value, but this information is required for downstream application provisioning

• Security incidents: Immediate access restrictions are needed before HR systems can be updated

• Temporary access grants: Providing temporary access while permanent changes are processed

To create an Override Value, perform the following:

1. Select an identity by name.

2. Click Details.

3. Click Properties in the Details menu.

4. Click Actions (three dots icon)

5. Select Create Override.

6. The Create Override window appears. The Property Name and Actual Value fields are populated.

7. Enter an Override Value.

8. Click Save.

Performing Actions on an Identity

Click the overflow icon (three dots) to display options for performing actions on the identity. Next, click on the desired action:

• Trigger Workflow

• Request Access

• Show in Graph

Trigger Workflow

The Trigger Workflow option is a convenient way to test a specific user in a policy workflow. For example, you can test a new employee's identity in a joiner workflow to evaluate whether they have sufficient access to perform their duties.

Use the Trigger Workflow option to manually run a workflow for a specific user.

To trigger a workflow with a specific user, perform the following steps:

1. Select a workflow in the dropdown menu.

2. Click Trigger to run the workflow.

Request Access for an Identity

Requests Access allows for additional or temporary access grants, particularly when a user’s current access is insufficient for their duties.

Use the Request Access option in the Identity Details view to grant access to a specific user while reviewing their detailed information. You can grant access to the user through the following actions:

Access Profiles: A collection of entitlements that are granted as part of the user’s identity lifecycle requirements. Access Profiles can:

• Define reusable collections of entitlements across multiple target systems by business roles, departments, or functions

• Automate consistent access provisioning

• Manage access profile types and their capabilities

See Access Profile and Access Profile Types for more information.

To grant an Access Profile, perform the following:

1. Click the Access Profile radio button.

2. The Choose from Access Profile window appears.

3. Enter a Reason for granting the Access Profile for the user.

4. Select an existing Access Profile from the dropdown menu.

5. Enter an Expiration Time in Hours or Days.

App: An App refers to a target system, where user access is provisioned or deprovisioned as part of the identity lifecycle process.

To grant an App, perform the following:

1. Click the Access Profile radio button.

2. The Request Grant Access window appears.

3. Enter a Reason for granting the App for the user.

4. Select an existing Integration from the dropdown menu.

5. Use the arrows to select an Expiration Time in Days, where 0 means no expiration.

6. Click Create.

Entitlements: Granting Entitlements to a user provides specific access permissions (roles, permissions, group memberships) required to perform their responsibilities.

Note: By granting Entitlements to a specific user, you pre-fill an Access Request with the appropriate configuration settings and policy.

To grant an Entitlement, perform the following:

1. Click the Entitlements radio button.

2. The Request Grant Access window appears.

3. Enter a Reason for granting the Entitlement for the user.

4. Select an existing Integration from the dropdown menu.

5. Based on the integration you selected, the Target Entity Type is automatically populated.

6. Use the arrows to select a Target Entitlement.

7. Use the arrows to select an Expiration Time in Days, where 0 means no expiration.

8. Click Create.

Show in Graph

Use the Show in Graph option to display a graph that represents all assigned Access Profiles, Apps, and Entitlements, including all associations.

This is a graphical representation of John Smith’s assigned access and entitlements to roles/groups.

Overview

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.

Prerequisites and Configuration

Before configuring the integration, ensure you have:

1. Administrative access in Veza to configure the integration

2. An existing in Veza or add a new one

3. At least one successful extraction from your Salesforce integration

4. The appropriate permissions in Salesforce

5. Salesforce API v40 or later for user provisioning

Required Permissions

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.

• Manage IP Addresses: Required for managing trusted IP ranges if IP restrictions are used.

• 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.

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.

SCIM Requirements

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 .

Enabling the Integration

To enable the integration:

1. In Veza, go to the Integrations overview.

2. Search for or create a integration.

   1. Ensure the integration permission set includes the .

3. Check the box to Enable usage for Lifecycle Management.

4. Save the configuration.

Configure the extraction schedule to ensure your Salesforce data remains current:

1. Go to Veza Administration > System Settings.

2. In Pipeline > Extraction Interval, set your preferred interval.

3. Optionally, set a custom override for Salesforce in the Active Overrides section.

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview.

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

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

SCIM Implementation Details

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

• User profiles are managed through SCIM entitlements

• 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

Supported Actions

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 :

Sync Identities

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).

• Passwords are set during user creation.

• Division and Department attributes are excluded during updates due to Salesforce API limitations.

• Salesforce does not support changing usernames after creation.

The following attributes can be synchronized:

Manage Relationships

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.

• Profiles: Manage profile assignments.

• User Roles: Synchronize user role 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.

• 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.

Deprovision Identity

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.

• The account can be reactivated if needed.

Overview

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.

Enabling Lifecycle Management for AWS IAM Identity Center

Prerequisites

1. You will need administrative access in Veza to configure the integration and appropriate permissions in AWS IAM Identity Center.

2. Ensure you have an existing in Veza or add a new one for use with Lifecycle Management.

3. Verify your AWS integration has completed at least one successful extraction

4. The AWS integration will need the additional required permissions for Identity Store operations:

   • 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

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

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create an AWS integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your AWS IAM Identity Center data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for AWS in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

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

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

Supported Actions

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 :

Sync Identities

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:

Manage Relationships

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

• Track membership changes for audit purposes

Deprovision Identity

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

• Account information is preserved for audit and compliance purposes

• Users can be reactivated if needed by updating the Active attribute

Create Entitlement

• 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

• Custom access policies and roles

Workflow Examples

Employee Onboarding

Automate the onboarding process for new employees:

1. Identity Creation: Create AWS IAM Identity Center user account with attributes synchronized from HR system

2. Group Assignment: Add user to department-specific groups based on their role and location

3. Permission Sets: Automatically assign appropriate permission sets for AWS resource access

4. Account Access: Grant access to specific AWS accounts based on job function

Role Change Management

Handle internal role changes and departmental transfers:

1. Attribute Update: Synchronize updated employee information from HR system

2. Group Reassignment: Remove user from previous department groups and add to new ones

3. Permission Adjustment: Update permission set assignments to match new role requirements

Employee Offboarding

Securely remove access when employees leave:

1. Account Deprovisioning: Disable the user account in AWS IAM Identity Center

2. Group Removal: Remove all group memberships and permission set assignments

3. Access Revocation: Ensure all AWS account access is immediately revoked

4. Audit Trail: Maintain complete record of access removal for compliance purposes