🔄Lifecycle Management
Overview of Veza provisioning capabilities
Early Access: This document describes Veza Lifecycle Management, an experimental feature that is currently in Early Access. To enable this feature, please contact our support team for assistance and guidance.
Please be aware that as an experimental feature, Veza Lifecycle Management may undergo changes and updates as we gather user feedback and work to enhance its capabilities. While we strive to provide a stable and reliable experience, there can be occasional issues or adjustments during this phase.
Your feedback and insights are highly valuable to us, and we encourage you to share your experiences with us as you explore Veza Lifecycle Management in its early stages. Your input will help us refine and improve this feature to meet your needs.
Overview
Veza Lifecycle Management allows you to define rules for creating, activating, and de-activating user accounts in a destination system (typically an identity provider such as Active Directory), based on changes in a source system (such as a birthright human resources platform).
Policies can apply at various stages of an identity's lifecycle. For example, you can trigger different workflows for:
Joiners: Create an Active Directory user and Exchange Server email based on Workday hire date, and record the email to the Workday profile.
Movers: Add an existing Active Directory user to new groups based on attribute changes in a source HRIS system.
Leavers: Change the status of an ENABLED Active Directory user to DISABLED based on a Workday termination date.
Provisioning rules can trigger based on changes within Workday, or based on user-submitted data using Open Authorization API (OAA). Lifecycle management currently supports the following capabilities for supported providers:
Active Directory: Create AD accounts with the specified AD groups (either Security Group or Distribution Group) and attributes.
Exchange Server: Create an email address for a specified AD account.
Workday: Detect changes, read attributes, and trigger provisioning flows.
Custom Identity Provider: Read Open Authorization API JSON payload to detect changes and trigger provisioning flows.
Lifecycle Management consists of:
Provisioning Rules for user creation and group assignment.
Configurations defining Access Profiles (groups of entitlements) and Business Roles (groups of access profiles, usually mapping to specific job responsibilities) assigned to users.
Provisioning Policies defining workflows and actions to apply based on changes in the source system.
Administrators can use a Dry Run to preview how provisioning rule changes will apply to any currently-provisioned user. A dry run can also preview how a to-be-provisioned user and its group assignment will be created based on a new user's attributes.
An Events log is also available to review all actions that have occurred, available from the Provisioning Rules page.
See Configuring Integrations for Lifecycle Management for details on enabling provisioning capabilities within supported integrations:
Source integration - Workday
Source integration - Custom IdP
Target integration - Active Directory
How it works
To enable provisioning, you will first need to:
Enable a provisioning source, either by adding a Workday integration, or by creating a custom identity provider and data source using the Open Authorization API (OAA).
Configure a provisioning target by adding a Microsoft Active Directory integration and granting Veza permission to manage users.
Optionally enable email creation and write-back to Workday by configuring an Exchange Server integration and enabling write capabilities for the Workday integration.
When Veza connects to a source provider, or when a custom data source is updated using OAA, any users that match a policy will cause provisioning actions to execute within the target integration. Veza will typically extract changes up to once an hour, or you can manually trigger a Workday extraction on the Configurations page.
The actions that trigger depend on the configured Provisioning Policies. Actions can include creating, disabling, or re-enabling an account. Provisioning Policies specify the actions to run when user attributes change from one value to another value matching the criteria set within the policy. For example, you can create policies for:
When a Workday Worker is added
When a Workday user is re-enabled
When a Workday Worker is terminated
Veza assigns attributes and groups to newly-created users based on the configured Provisioning Rules. For example, different user and group creation rules can be specific to Workers within a given Workday cost center, position, or department. These users can be assigned to different Active Directory OUs or assigned other attributes based on mappings defined within the rules.
If a policy is paused, Veza will still detect changes and queue provisioning actions. However, actions will not trigger until the policy resumes.
Testing
You can use the following steps as a guideline for validating that Lifecycle Management actions are working as intended for both Workday and a Custom Identity Provider. Omit Workday, Exchange Server, or Custom Identity Provider testing, depending on your needs:
Provisioning setup
Add integrations and enable provisioning.
Push Custom IdP user data.
Perform Workday Extraction.
Confirm Authorization Graph data.
Create Access Profiles and Business Roles.
Create User Mapping Rules.
Create Group Membership Rules.
Perform Dry Run.
Create Provisioning Policies.
Pause Custom IdP Policies.
Provision users
Push Custom IdP user data with new users.
Perform Workday Extraction.
View Provisioning Events log.
Verify Custom IdP tasks were created but not started.
Verify Workday workers are created in AD and added to groups.
Verify Exchange email creation.
Un-pause policies for Custom IdP.
Verify Custom IdP users are created in AD and joined to groups.
De-provision users
Push Custom IdP user data with terminated users.
Verify users are disabled and added to the expected groups.
Re-enable users
Push Custom IdP user data with re-activated users.
Verify Custom IdP users are re-enabled in AD and re-joined groups.
Last updated