Implementation and Core Concepts

Before you begin creating draft Policies for automating Lifecycle Management workflows, you should establish and document how employees in your organization are mapped to business roles, and corresponding birthright entitlements (default access permissions granted based on an employee's role) such as groups and roles in target applications.

Implementing Veza Lifecycle Management will require:

• Defining segmentation criteria in terms of Business Roles for identities in your organization.

• Defining Role Conditions used in Lifecycle Management policies that Veza will use to match roles to identities, based on attributes from the source of identity.

• Defining Profiles for each target application that will map Business Roles to application-specific entitlements.

• Assigning Profiles to Business Roles to enable business rules.

The topics in this document will help you structure your Lifecycle Management implementation, and establish foundations that you can use to simplify access management throughout the employee lifecycle.

Key considerations and requirements

• Is a lifecycle management process defined for your organization?

  • If yes: Begin assessing your current policies for implementation with Veza Lifecycle Management.

  • If no: Work with application owners, HR administrators, and other stakeholders to establish protocols for granting and revoking access as employees join, depart, or change roles.

• Do you have one, or even multiple sources of truth for employee identity metadata?

  • At least one source of identity is required to trigger Lifecycle Management actions when there are changes in the data source. This data source could be an HRIS system, identity provider, directory service, or an exported report.

  • Veza supports importing employee records from built-in integrations, OAA integrations using the Custom HRIS template, and CSV upload.

  • For example, you may have different sources of identity for full-time and employees and contractors.

• What scenarios will be automated?

  • A range of applications can be sources of identity and targets for Lifecycle Management, with different actions supported for each integration. See Actions and Integrations for the current capabilities.

Define Segmentation Criteria (Business Roles)

Begin by identifying and cataloging the different roles that can be assigned to employees and their digital identities within your organization. Users will be granted entitlements within target applications based on these business roles based on your Lifecycle Management policies.md.

This list of business roles might be sourced from an organization chart, or a human resources information system (HRIS). These roles can be defined in terms of any discriminating attributes from a source of identity, such as:

1. Employee or contractor status

2. Roles and job positions

3. Business Units (BUs)

4. Locations

5. Define and list the different populations of employees with different levels of access in your organization (such as by roles, regions, and teams).

6. Organize the populations hierarchically, each inheriting the access granted to its parent population. For example, you might have a structure "All Employees" > "Sales Team" > "Sales Managers," with each inheriting the access granted to the parent.

7. Create a Business Role in Veza to model each segment.

Example Business Roles:

• Sales

• Developers

• Executive Employees

• US Employees

• China Employees

Define Role Conditions

Identify the attributes and conditions that will identify the segment each user belongs to. The possible attributes will depend on the employee metadata provided by your HRIS or other source of truth for identity.

For example, you might assign certain Active Directory groups only to US employees, identified by a source Workday Worker's work_location. To define these conditions, you will need to understand what attributes are available within the source of truth, and how the values map to each employee segment.

1. Consider how employee records are structured in your source of identity, including all the built-in attributes belonging to an identity, and the possible values.

2. Check if any custom attributes can be used to define role conditions, and ensure these are enabled in the Veza authorization graph.

3. Document how employee populations correspond to the attribute values contained in the source of identity.

Examples: Source attributes for role conditions

The following standard attributes are available by all HRIS integrations that use an Open Authorization API template, along with any custom properties enabled for the integration. You can typically import data from any HRIS system to Veza using this template, sourced from a generated report, API calls, or CSV data.

OAA HRIS Built-In Attributes

Attribute	Description
Employee Number	Unique identifier for the employee.
Company	The company or subsidiary the employee works for.
First Name	Employee's first name.
Last Name	Employee's last name.
Preferred Name	Employee's preferred first name.
Display Full Name	Full name for display; includes preferred first name if available.
Canonical Name	Employee's canonical name.
Username	Username as shown in the integration UI.
Email	Employee's work email (unique).
IDP ID	ID for connecting to the destination IDP provider.
Personal Email	Employee's personal email.
Home Location	Employee's home location.
Work Location	Employee's work location.
Cost Center	Cost center ID associated with the employee.
Department	Department ID (Group ID) of the employee.
Managers	List of employee IDs of the employee's managers.
Groups	List of group IDs the employee is associated with.
Employment Status	Employment status, e.g., ACTIVE, PENDING, or INACTIVE.
Is Active	Indicates if the employee is active.
Start Date	The date the employee started working.
Termination Date	Employee's termination date, if applicable.
Job Title	Employee's job title.
Employment Types	Type of employment, e.g., FULL_TIME, PART_TIME, INTERN, CONTRACTOR, or FREELANCE.
Primary Time Zone	Employee's primary time zone.

Using this standard identity metadata, a Lifecycle Management workflow runs specific actions for identities where some or all of the conditions are true:

• Employment Status equals "Pending"

• Employment Types equals "Full Time"

• Department equals "Engineering"

• Work Location equals "US"

• Cost Center equals "R&D"

• Start Date on or after "2025-01-01"

Define Profiles

A Profile defines a set of entitlements for a specific application that can be assigned to users. For each target application, application owners will need to establish levels of birthright entitlements by defining Profiles mapped to groups, roles, or other entitlements that can be assigned to a user.

1. Review target applications to validate that the expected entitlements are configured, with the correct scopes and permissions for the Profiles they will be associated with.

2. Create Lifecycle Management Access Profiles mapped to those entitlements.

Examples: Access Profiles

Profile Name	Target	Relationship
AD Executive Employees	Active Directory	Executive Employee - Manager US (Active Directory Group)
AD Engineering Managers	Active Directory	Engineering - Manager US (Active Directory Group)
Azure Helpdesk Role	Azure	Helpdesk Administrator (Azure AD Role)
Google China Employees	Google Cloud	Google China Employees (Google Group)

When configuring the Manage Relationships action, administrators can grant or revoke access by choosing a Business Role that inherits the desired Profile.

Map Business Roles to Profiles

Configure Business Roles to inherit the corresponding access profiles, mapping entitlements to employee segments.

1. Create Business Roles for each segment.

2. For each Business Role, inherit a corresponding access profile.

3. Assign one or more Profiles to each Business Role as needed to fully define the birthright entitlements for each position.

Examples: Map Business Roles to Profiles

Asia Employees

US Employees

Developers

Define synced attributes

Attributes from the source of identity can determine the attributes of users in target systems when creating or updating a target entity.

For example, a provisioned Okta User's country_code might be set to a source Workday Worker's work_location. Additionally, the Okta User manager attribute could be continually synchronized to match the Worker’s manager.

Target synced attributes can have fixed values (e.g., always true), can match a source attribute, or contain a combination of source values, transformed as needed to match the required format. Rules for synchronizing attributes are managed with Transformers.

1. For each application, understand the supported attributes for provisioned users.

2. Assess the identity metadata from your source of truth to decide how source entity attributes will be used to set the values of target entity attributes.

3. Veza can synchronize attributes during provisioning and de-provisioning workflows, and whenever a change is detected in the source of identity. Decide which attributes should be kept in Continuous Sync, and which should only be created (and never modified after creating an entity).

Examples: Synced Attributes

Sync Active Directory Accounts for Active Employees (Joiners/Movers)

When provisioning AD Users, create user attributes based on values in the source of identity. These attributes can also be kept up-to-date with the source of identity when there are changes, by enabling Continuous Sync.

Active Directory Attribute	Source Attributes	Transformer Value
account_name	display_full_name	{display_full_name}
distinguished_name	first_name, last_name	CN={first_name} {last_name},OU=Minnetonka,OU=US,OU=Evergreen Staff,DC=evergreentrucks,DC=local
user_principal_name	username	{username}@evergreentrucks.com
email	username	{username}@evergreentrucks.com
display_name	display_full_name	{display_full_name}
given_name	first_name	{first_name}
sur_name	last_name	{last_name}
country_code	work_location	{work_location}
job_title	job_title	{job_title}
primary_group_dn	-	CN=Domain Users,CN=Users,DC=evergreentrucks,DC=local

Sync Active Directory Attributes for Withdrawn Employees (Leavers)

When disabling AD Users, update the DN and Primary Group DN to a group and OU reserved for terminated employees:

Active Directory Attribute	Source Attributes	Transformer Value
account_name	display_full_name	{display_full_name}
distinguished_name	first_name, last_name	CN={first_name} {last_name},OU=Evergreen Termination,OU=Evergreen Staff,DC=evergreentrucks,DC=local
primary_group_dn	-	CN=Terminated Users,OU=Evergreen Groups,DC=evergreentrucks,DC=local

• Moving leavers into a "Terminated Users" group (via the primary_group_dn attribute) effectively restricts access to systems that rely on Active Directory for authentication and authorization.

• Updating the distinguished_name to place leavers in a specific organizational unit (OU), like "Evergreen Termination," separates active users from inactive ones, and enables the application of policies, scripts, and queries that target inactive users without affecting active employees.