Lifecycle Management with Workday, Okta, and Active Directory

A well-designed identity Lifecycle Management solution automates the provisioning, synchronization of attributes and metadata, and deprovisioning of user accounts across your application and systems ecosystem.

This guide demonstrates how to implement a worker (employees and contractors) Lifecycle Management solution using Workday as the source of identity with downstream user account provisioning and synchronization platforms of Okta and Active Directory (AD). This represents a common enterprise architecture where worker records originate in an HR system and are provisioned to identity and access management systems, while maintaining a seamless, secure, and compliant user lifecycle process.

System Architecture

The following diagram shows the complete identity provisioning and synchronization architecture from Workday, a human capital management platform, to Okta and Active Directory, which are identity management systems:

The "Joiner Mover Leaver" (JML) process is a framework for managing users' employment lifecycle access within an organization. Provisioning access begins with onboarding new employees (Joiners), then managing internal transitions (Movers), and finally offboarding departing employees (Leavers).

Lifecycle Management is based on the JML paradigm, where Workday is the authoritative source of identity, which is monitored for the status of the worker based on attributes in their record to determine whether the user is a joiner, mover, or leaver.

JML Process Flow

The joiner, mover, leaver (JML) process flows through the systems as follows:

Prerequisites

Before starting this implementation, ensure you have:

1. Configured Workday for Lifecycle Management

2. Configured Okta for Lifecycle Management

3. Configured Active Directory for Lifecycle Management

4. Completed at least one successful extraction for each integration

   Note: An extraction is the metadata ingestion process that pulls identity and permission data from target systems into Veza, enabling it to act across access policies, governance, and provisioning workflows.

5. Administrative access to Veza to create Lifecycle Management policies

Implementation Steps

Step 1: Define Access Profiles

First, create Access Profiles that define which application entitlements a group of users will be assigned:

1. Go to Lifecycle Management > Access Profiles

2. Click Create Access Profile

3. Configure a profile for each department or role:

Example: Engineering Department Profile

Name: Engineering Department Access
Profile Type: Application Entitlements 
Description: Standard access for Engineering department employees
Label: Developers

Entitlements:
- Active Directory Group: Engineering
- Okta Group: Engineering

Example: Marketing Department Profile

Name: Marketing Department Access
Profile Type: Application Entitlements
Description: Standard access for Marketing department employees

Entitlements:
- Active Directory Group: Marketing
- Okta Group: Marketing

Create additional profiles as needed based on your organizational structure.

Step 2: Create a Lifecycle Management Policy associated with Workday

Next, create a Lifecycle Management policy using Workday as the source of identity:

1. Navigate to Lifecycle Management > Policies

2. Click Create Policy

3. Configure the policy:

   • Name: Workday Employee Lifecycle

   • Source of Identity: Workday

   • Data Source: Your Workday integration

   • Entity Type: Workday Worker

4. Click Create Policy to save the basic configuration

Step 3: Configure Joiner Workflow

Now add a workflow for new employee onboarding:

1. Edit your Workday Employee Lifecycle policy

2. Click Add Workflow

3. Configure the workflow:

   • Workflow Name: Active Employee

   • Condition: is_active eq true AND hire_date eq "2025-08-04T00:00:00" This condition is triggered when, in Workday, the employee is active and a defined hiring date is "2025-08-04T00:00:00". Therefore, any active employee hired on or after the specified date is considered a joiner.

   • Continuous Sync: Enabled Continuous Sync is enabled, allowing updates to a user's source attributes—such as email, department, manager, or role—to be automatically synchronized to the target application on an ongoing basis after the user is provisioned.

4. Add actions to the workflow as detailed in the Configuration Reference section.

Step 4: Configure Mover Workflow

Add a workflow for handling employee role changes:

1. Edit your Workday Employee Lifecycle policy

2. Click Add Workflow

3. Configure the workflow:

   • Workflow Name: Mover Workflow - Regional Sales Manager

   • Condition: is_active eq true AND first_name eq “Sarah” AND last_name eq “Johnson” AND position eq “Regional Sales Manager”

   • Continuous Sync: Enabled

4. Add actions similar to the Joiner workflow, but ensure Remove Existing Relationships is enabled in the Manage Relationships actions to update group memberships when departments change When a user’s role changes (mover), you often need to revoke existing entitlements—like group memberships, role assignments, and permission set grants—not just avoid adding new ones. Enabling Remove Existing Relationships ensures that previously granted relationships are actively removed to prevent privilege creep or orphaned access.

Step 5: Configure Leaver Workflow

Finally, add a workflow for employee termination:

1. Edit your Workday Employee Lifecycle policy

2. Click Add Workflow

3. Configure the workflow:

   • Workflow Name: Employee Termination

   • Condition: is_active eq false OR termination_date eq "2025-08-08T00:00:00" This condition is triggered when the employee is no longer active and a defined termination date is "2025-08-08T00:00:00". Therefore, any non-active employee terminated on or after the specified date is considered a leaver.

4. Add deprovisioning actions, such as Deprovision Okta Identities and Deprovision AD Identities

Step 6: Enable and Test the Policy

After configuring your workflows for joiners, movers, and leavers, you can test your policy using Simulated Dry Runs to check the expected actions when executed.

Another approach to test your policy is to create draft versions. You can make changes to your policy as an iterative draft until you are satisfied with the results. You can then publish the final version and enable it.

As a final verification, make modifications to the Workday application to test your policy's expected performance. Ensure that the downstream applications, Okta and Active Directory, are correct with the modifications.

Test using Simulation Dry Run

1. Select Workday Employee Lifecycle policy.

2. Click the overflow menu (three dots icon) at the top of the page.

3. Select Perform Dry Run.

4. In the Identity field, select an employee name from the dropdown menu.

5. The Dry Run takes seconds to execute. Click Show results.

6. Ensure that Okta and Active Directory contain the correct identity information for the employee.

Test using Draft Versioning

1. Select Workday Employee Lifecycle policy.

2. Click Create Draft.

3. Select Edit Workflow.

4. Modify any workflow in your policy.

5. Click Save Workflow. The workflow is now a draft version.

6. Continue to iterate on changes to the workflow until it is ready.

7. Click Publish when the policy performs satisfactorily.

8. Click Settings at the top of the page.

9. Click Policy Settings.

10. Enable the Enable Policy Draft Mode radio button.

11. In the Policy page, select your policy and click Actions.

12. In the Actions menu, select Start.

Make changes to the Workday application to test your policy

In your Workday application, update the source of identity to test your policy. The following is a list of suggested changes:

• Change the employee’s employee type (ie, from regular to contractor)

• Verify account creation in Okta and Active Directory

• Change the employee's department and verify group membership updates

• Terminate the employee and verify account deprovisioning

Identity Synchronization Configuration Reference

Identity Synchronization is implemented during Lifecycle Management provisioning workflows. It is used to prevent provisioning errors due to duplication of username and/or email address. It supports robust identity sync across downstream applications (Okta and Active Directory) with different naming constraints or enforces unique identifiers.

Use Identity Synchronization if your target system already has an identity with a given attribute (e.g., a username or email is already in use).

Enable Identity Synchronization

1. In the Policy page, select your policy, Workday Employee Lifecycle policy.

2. Select Policy Settings.

3. Scroll down to Advanced Settings.

4. Under Identity Syncing, enable Sync on changes only or Always sync.

Sync Okta Identities

Synchronizes employee records to Okta user accounts, creating and updating user profiles with mapped worker attributes from Workday.

Configuration:

• Description: Synchronizes identities to Okta

• Target: OktaUser

• Create Allowed: Yes

• Continuous Sync: Yes

Attribute Mappings

Conditional Actions

All Employees

• Assigns "All Okta Employee Access" profile

• Does not remove existing relationships

US Developers

• Condition: wd_location eq "US" and department eq "developer"

• Assigns developer-specific access profiles

• Does not remove existing relationships

Sync Active Directory Identities

Creates and updates on-premises Active Directory accounts with location-specific group assignments and standardized naming conventions for different employee categories.

Configuration:

• Description: Synchronizes identities to Active Directory

• Target: ActiveDirectoryUser

• Create Allowed: Yes

• Continuous Sync: Yes

Attribute Mappings

Conditional Actions

US Location

• Condition: work_location eq "US"

• Assigns US Groups

• Removes existing relationships

Executive Group

• Condition: employee_group eq "Executive"

• Assigns the Executive Employee group

• Removes existing relationships

China Location

• Condition: work_location eq "China"

• Assigns China Groups

• Removes existing relationships

Deprovisioning Configuration Reference

Defines the procedures for safely removing access when employees leave the organization, including specific handling for each identity provider.

Deprovision Okta Identities

Handles employee offboarding in Okta by disabling accounts while preserving access history and configurations.

Configuration:

• Description: Disables identities in Okta

• Target: OktaUser

• Remove Relationships: No

• Deprovisioning Method: Disabled

• Logout User: No

• Remove Personal Devices: No

Deprovision Active Directory Identities

Controls the offboarding process for on-premises Active Directory, including moving accounts to a terminated user's organizational unit.

Configuration:

• Description: Disables identities in Active Directory

• Target: ActiveDirectoryUser

• Remove Relationships: No

• Deprovisioning Method: Disabled

Attribute Transformations

Expanded Joiner/Mover/Leaver Scenarios

Below are more detailed examples of joiner, mover, and leaver scenarios that you can implement using Veza's Lifecycle Management.

Joiner Scenarios

Example 1: Full-Time Employee Onboarding

Trigger: New employee record created in Workday with status="Active" and worker_type="Full_Time"
Actions:
1. Create Okta user with attributes from Workday transformer
2. Assign to department-specific groups in Okta
3. Create AD user with attributes from Workday transformer
4. Add to appropriate security groups in AD based on job role
5. Send welcome email with account information

Example 2: Contractor Onboarding

Trigger: New worker record created in Workday with status="Active" and worker_type="Contractor"
Actions:
1. Create Okta user with limited attribute set and "Contractor-" prefix in username
2. Assign to contractor-specific groups in Okta
3. Create time-limited AD account with expiration date set to contract end date
4. Add to contractor security groups with restricted access
5. Send welcome email with temporary password and access instructions

Mover Scenarios

Example 1: Department Change

Trigger: Employee department changed in Workday
Actions:
1. Update department attribute in Okta and AD
2. Remove previous department group memberships in both systems
3. Add new department group memberships in both systems
4. Update OU placement in AD
5. Send notification to new manager

Example 2: Promotion to Manager

Trigger: Employee job level changed to include management flag
Actions:
1. Update job title in all systems
2. Add to manager-specific groups in Okta and AD
3. Add to approval workflows in relevant systems
4. Send manager training notification

Leaver Scenarios

Example 1: Standard Termination

Trigger: Employee status changed to "Terminated" in Workday
Actions:
1. Disable user in Okta and AD (do not delete)
2. Remove all group memberships
3. Revoke all application access
4. Move AD account to "Terminated Users" OU
5. Generate access termination report for compliance

Example 2: Involuntary Termination (Security Risk)

Trigger: Employee terminated with reason="Security Risk"
Actions:
1. Immediately disable all accounts (high priority)
2. Force logout from all active sessions
3. Reset all passwords
4. Remove all access rights and group memberships
5. Generate security incident report

Advanced Attribute Transformer Examples

Workday to Okta Transformer (Enhanced)

# Okta User Attributes
login: {worker_id}@company.com
email: {work_email | DEFAULT, "{worker_id}@company.com"}
first_name: {first_name}
last_name: {last_name}
display_name: {first_name} {last_name}
department: {department_name}
title: {job_title}
manager_id: {manager_worker_id}@company.com
# Handle different user types
user_type: {worker_type | LOWERCASE | REPLACE, "full_time", "Employee" | REPLACE, "contractor", "Contractor" | DEFAULT, "Employee"}
employee_id: {employee_id}
# Custom attributes
customField1: {location_code}
customField2: {hire_date | DATE_FORMAT, "yyyy-MM-dd"}
customField3: {termination_date | DATE_FORMAT, "yyyy-MM-dd" | DEFAULT, ""}

Workday to Active Directory Transformer (Enhanced)

# AD User Attributes
account_name: {worker_id}
# Build distinguished name based on employment type and department
distinguished_name: {worker_type | EQUALS, "contractor" | IF_TRUE, "CN={first_name} {last_name},OU=Contractors,OU={department_name},DC=company,DC=local" | IF_FALSE, "CN={first_name} {last_name},OU=Employees,OU={department_name},DC=company,DC=local"}
user_principal_name: {worker_id}@company.local
email: {work_email | DEFAULT, "{worker_id}@company.com"}
display_name: {first_name} {last_name}
given_name: {first_name}
sur_name: {last_name}
department: {department_name}
job_title: {job_title}
description: {job_title} - {department_name}
company: Company Inc.
# Set account expiration for contractors
account_expires: {worker_type | EQUALS, "contractor" | IF_TRUE, {contract_end_date} | IF_FALSE, ""}
# Custom attributes
extension_attribute_1: {cost_center}
extension_attribute_2: {business_unit}
extension_attribute_3: {hire_date | DATE_FORMAT, "yyyy-MM-dd"}
extension_attribute_4: {employee_id}

Advanced Configuration

Using Attribute Overrides

To handle edge cases where standard attribute formatting is not effective, use Identity Override Attributes to define special exceptions. For example:

• Contractors vs. Employees: Use different username formats based on employment type

• Username Conflicts: Configure fallback formatters for handling duplicate usernames

• Location-Specific Naming: Apply different naming conventions based on location or region

Email Write-Back to Workday

Ensure your email addresses remain consistent by configuring email write-back to Workday:

1. In your Joiner workflow, after the Sync Identities actions, add:

   • Add Action > Create Email

   • Configure for your email system

2. Then add:

   • Add Action > Write Back Email

   • Integration: Your Workday integration

   • Entity Type: Workday Worker

This ensures the email created in your systems is written back to Workday as the source of truth.

Conditional Logic Best Practices

When implementing conditional actions, consider these patterns for robust lifecycle management:

Location-Based Conditions

# US-based employees
work_location eq "US"

# International employees requiring different treatment
work_location eq "China" OR work_location eq "EMEA"

# Remote workers
work_location eq "Remote" OR office_location contains "Remote"

Role-Based Conditions

# Technical roles requiring elevated access
department eq "Engineering" OR department eq "DevOps" OR job_title contains "Developer"

# Management roles
job_level eq "Manager" OR job_level eq "Director" OR job_level eq "VP"

# Sensitive roles requiring additional security
department eq "Finance" OR department eq "Legal" OR department eq "HR"

Employment Type Conditions

# Full-time employees
worker_type eq "Full_Time" AND status eq "Active"

# Contractors with time-limited access
worker_type eq "Contractor" AND contract_end_date is not null

# Temporary workers
worker_type eq "Temporary" OR employment_status eq "Temp"

Monitoring and Troubleshooting

Activity Log Monitoring

Monitor your lifecycle management workflows using the Activity Log:

1. Navigate to Lifecycle Management > Activity Log

2. Filter by policy name to see all actions for your Workday policy

3. Look for failed actions and investigate error messages

4. Use the activity details to verify that transformations are working correctly

Common Issues and Solutions

Username Conflicts

If usernames are already taken in target systems:

• Configure Fallback Formatters to handle conflicts

• Use employee ID or other unique identifiers as backup username formats

Missing Attributes

If required attributes are missing from Workday:

• Use DEFAULT transformers to provide fallback values

• Configure conditional logic to handle missing data gracefully

Group Assignment Failures

If group assignments fail:

• Verify that referenced groups exist in target systems

• Check that service accounts have sufficient permissions

• Use conditional logic to assign groups only when they exist