Lifecycle Management with Workday, Okta, and Active Directory

Guide for implementing automated user lifecycle management across 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:

Configured Workday for Lifecycle Management
Configured Okta for Lifecycle Management
Configured Active Directory for Lifecycle Management
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.
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:

Go to Lifecycle Management > Access Profiles
Click Create Access Profile
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:

Navigate to Lifecycle Management > Policies
Click Create Policy
Configure the policy:
- Name: Workday Employee Lifecycle
- Source of Identity: Workday
- Data Source: Your Workday integration
- Entity Type: Workday Worker
Click Create Policy to save the basic configuration

Step 3: Configure Joiner Workflow

Now add a workflow for new employee onboarding:

Edit your Workday Employee Lifecycle policy
Click Add Workflow
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.
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:

Edit your Workday Employee Lifecycle policy
Click Add Workflow
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
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:

Edit your Workday Employee Lifecycle policy
Click Add Workflow
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.
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

Select Workday Employee Lifecycle policy.
Click the overflow menu (three dots icon) at the top of the page.
Select Perform Dry Run.
In the Identity field, select an employee name from the dropdown menu.
The Dry Run takes seconds to execute. Click Show results.
Ensure that Okta and Active Directory contain the correct identity information for the employee.

Test using Draft Versioning

Select Workday Employee Lifecycle policy.
Click Create Draft.
Select Edit Workflow.
Modify any workflow in your policy.
Click Save Workflow. The workflow is now a draft version.
Continue to iterate on changes to the workflow until it is ready.
Click Publish when the policy performs satisfactorily.
Click Settings at the top of the page.
Click Policy Settings.
Enable the Enable Policy Draft Mode radio button.
In the Policy page, select your policy and click Actions.
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

In the Policy page, select your policy, Workday Employee Lifecycle policy.
Select Policy Settings.
Scroll down to Advanced Settings.
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

Destination Attribute

Source/Format

Continuous Sync

Notes

{username}@sigmacorpx.com

Yes

first_name

{first_name}

Yes

last_name

{last_name}

Yes

country_code

{work_location}

Yes

{username}@sigmacorpx.com

Common transformer

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

Destination Attribute

Source/Format

Continuous Sync

Notes

distinguished_name

CN={first_name} {last_name},OU=Minnetonka,OU=US,OU=Evergreen Staff,DC=evergreentrucks,DC=local

Yes

See Microsoft Lightweight Directory Access Protocol for more information on distinguished_name.

user_principal_name

{username}@evergreentrucks.com

Yes

{username}@evergreentrucks.com

Yes

display_name

{display_full_name}

Yes

given_name

{first_name}

Yes

sur_name

{last_name}

Yes

country_code

{work_location}

Yes

job_title

{job_title}

Yes

primary_group_dn

CN=Domain Users,CN=Users,DC=evergreentrucks,DC=local

Yes

account_name

{display_full_name}

Common transformer

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

Destination Attribute

Value

Continuous Sync

distinguished_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

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:

In your Joiner workflow, after the Sync Identities actions, add:
- Add Action > Create Email
- Configure for your email system
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:

Navigate to Lifecycle Management > Activity Log
Filter by policy name to see all actions for your Workday policy
Look for failed actions and investigate error messages
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

PreviousNotification Templates for Lifecycle Management NextIntegrations

Last updated 8 days ago

Was this helpful?