Attribute Mapping

How source system properties become Veza attributes

Overview

When connecting to integrated systems (see Veza Integrations), Veza ingests properties from the source systems (e.g., Workday, Okta, Active Directory) and normalizes them into standardized attributes that appear when configuring Workflow trigger conditions, configuring Actions, and in Identities views.

While these standardized attributes are intended to ensure consistent naming across different systems, it is important to understand that some attributes may appear differently than their original names in the source system.

You can retrieve the original attribute names for enabled Lifecycle Management integrations using the ListLifecycleManagerDatasources API.

Attribute Naming Conventions

Veza normalizes all property names for consistency:

Original Format	Veza Format	Rule Applied
Employee ID	employee_id	Spaces → underscores
BusinessTitle	business_title	CamelCase → snake_case
Cost-Center	cost_center	Special chars removed
Department Code	customprop_department_code	Custom fields prefixed

The following normalization rules typically apply:

• Source properties are converted to lowercase

• Any spaces and hyphens become underscores

• Special characters removed

• CamelCase converted to snake_case

• Custom fields are identified with a customprop_ prefix

• System-computed fields are identified with the sys_attr__ prefix

Attribute Types and Mappings

The following sections include some examples of how Veza handles attributes from common integrations.

Standard Attributes

Veza recognizes and standardizes many common attributes across source systems:

Attribute	Type	Description	Example Value
employee_id	string	Employee identifier	E-98765
email	string	Primary email	[email protected]
department	string	Department name	Engineering
title	string	Job title	Senior Engineer
business_title	string	Business position	Senior Engineer
manager	string	Manager reference	[email protected]
managers	list	List of managers	[John Smith]
is_active	boolean	Active status	true
hire_date	date	Employment start date	2024-01-15
cost_center	string	Financial allocation	CC-1000

Source-Specific Mappings

Veza will make conversions to some attribute names from the source integration. For example, sAMAccountName in Microsoft Active Directory is shown as account_name for Active Directory Users in Veza Access Graph.

Workday → Veza

Workday Property	Veza Attribute	Notes
Worker ID	workday_id	Unique worker identifier
Employee ID	employee_id	Employee number
Business Title	business_title	Job position
Cost Center	cost_center	Financial allocation
Employee Type	employee_types	List (e.g., Full Time)
Manager	managers	List of manager names

Okta → Veza

Okta Property	Veza Attribute	Notes
login	login	Username
email	email	Primary email
status	status	ACTIVE, SUSPENDED, etc.
department	department	Department name
manager	manager	Manager's email/ID

Active Directory → Veza

AD Property	Veza Attribute	Notes
sAMAccountName	account_name	Pre-Windows 2000 login
distinguishedName	distinguished_name	Full LDAP path
userPrincipalName	user_principal_name	user@domain format
memberOf	member_of	List of group DNs
department	department	Department name
title	title	Job title

Custom Properties

Some integrations support custom property extraction for organization-specific fields from custom reports or extended schemas:

• Always prefixed with customprop_

• Automatically discovered during extraction once enabled

• Follow standard normalization rules (lowercase, underscores)

Examples:

• customprop_department_code - Custom department identifier

• customprop_employeeou - Organizational unit

• customprop_region - Geographic region

• customprop_project_code - Project allocation

System Attributes

Some entity attributes are computed by Veza, and not derived from source data:

• sys_attr__is_mover - Identity has changed monitored properties

• sys_attr__would_be_value - Preview value in conditional transformers

• sys_attr__would_be_value_len - Preview value length in conditional transformers

See System Attributes for details.

Using Attributes in Workflows

When configuring a Workflow trigger condition or an action that syncs attributes, you can choose from available attributes using a dropdown menu.

Selecting attributes in a workflow trigger condition.

Primary vs Secondary Sources

Primary Source - Attributes from the main identity source appear without prefixes:

workday_id
employee_id
business_title
hire_date
email
customprop_department_code

Secondary Sources - Attributes from additional sources are prefixed with the entity type:

OktaUser.login
OktaUser.department
AzureADUser.job_title
ActiveDirectoryUser.distinguished_name

Example Usage

In Workflow Conditions:

employee_types co "Full Time" and department eq "Engineering"

In Transformers:

{first_name}.{last_name}@{customprop_domain}.com

With Secondary Sources:

OktaUser.status eq "ACTIVE" and WorkdayWorker.is_active eq true

See Also

• System Attributes - Computed attributes for advanced scenarios

• Transformers - Modifying and combining attribute values

• Policies - Using attributes in workflow conditions