Attribute Transformers

Configure how user attributes from a source of identity are transformed for target user accounts

When creating workflows in Lifecycle Management policies to create, sync, or deprovision identities, you will use attribute transformers to specify how user attributes for target accounts should be structured.

The target attributes to create or update are typically mapped and, optionally, transformed from user metadata in the source of identity, such as an identity provider, HR system, or CSV upload. Attributes can be synchronized once or kept continuously in sync as changes occur throughout the user's employment lifecycle.

Attribute transformers are also available when mapping columns in CSV Upload integrations. This enables you to combine columns, reformat dates, standardize case, and apply other transformations during CSV import—without requiring Lifecycle Management workflows.

For example, attribute mapping and transformation can be used across Joiner, Mover, and Leaver scenarios:

• Joiner: Set new Azure AD User Principal Name to {source username}@your-email-domain.com. This is an example of mapping multiple attributes and performing a transformation. More specifically, you use the attribute transformer to generate an email address for new joiners. Use the source username (user_principal_name) from the source of identity (Azure AD UPN) for the first part (user attribute), while your-email-domain.com is used for the last part (target attribute).

• Mover: Always update a user’s “Manager” and “Department” attributes in Okta to match the user’s manager and department in Workday, a source of identity, whenever a department change or other employee mobility event occurs. This is an example of attribute mapping with continuous synchronization.

• Leaver: Move a user’s Active Directory account to an Organizational Unit (OU) reserved for terminated accounts.

When synchronizing a user’s attributes, Veza may apply many transformations to convert the source attribute values into a more suitable format intended for the target application as a user account attribute.

For example, a transformer might remove the domain from an email address, replace special characters, or convert a string with uppercase letters to lowercase letters.

See Attribute Synchronization for detailed information.

Key Terminology

Term	Description	Examples
Source of Identity (SOI)	The system holding authoritative user data—the "source of truth"	HR systems (Workday, BambooHR), identity providers (Azure AD, Okta), CSV uploads
Target Application	The system where user accounts are created or updated using SOI data	Active Directory, Okta, Google Workspace, SaaS applications

Adding transformers

Common transformers define one or more rules to apply when synchronizing the attributes of a target identity. Use them at the Policy level where you want to create or update attributes using the same conventions across multiple sync or deprovision actions. When you need to configure a one-time individual action in a workflow, such as a specific attribute, then you use the transformer at the Action level.

At the Policy level, you configure a transformer with basic details, including how to source the value of each attribute:

1. Assign a name and description to the transformer, and specify the data source to which it applies.

2. Entity Type: Choose the target entity type in the destination system.

3. Click Add Attribute. The Destination Attribute dropdown will list available attributes for the chosen entity type.

   • Destination Attribute: Choose the attribute that Veza will create or update for the target entity.

   • Formatter: Choose how the destination attribute should be formatted. Specify the value, a {source_attribute}, or apply Transformation Functions.

   • Pipeline Functions: Combines a series of attribute formatters with the pipe ( | ) character that runs the value of an attribute in sequential order, where the output of one formatter becomes the input of the following formatter, thus the name, pipeline.

   See Pipeline Functions for more examples.

   • Continuous Sync: Enabling this option ensures that the attribute is always synced, while applying any defined transformations. By default, attributes will not be synced if the target identity already exists.

After creating a common transformer, you can select it when editing a workflow action. You can edit or delete common transformers on the Edit Policy > Common Transformers tab. Remember that “Sync Identity” and “De-Provision Identity” actions can have action-level transformers override common transformers. If the same destination attribute is defined in both, the action-level transformer will take precedence.

Formatters

Formatters specify the actual value of the attribute to synchronize. The target attribute can be set to a specific value, synchronized with a source attribute, transformed using a function, or a combination of these.

Some formatters should enable continuous synchronization for the attribute, while others should not. For example, the value of "Created By" should be immutable once a user account is provisioned. Other attributes that represent a state or status should be synchronized throughout the user's or account's lifecycle.

Simple Value Setting

To create a destination attribute with a fixed value, enter the desired value when configuring the formatter. For setting the creator attribute:

Destination Attribute	Formatter	Continuous Sync
created_by	“Veza”	Disabled

For activating a re-hired employee:

Destination Attribute	Formatter	Continuous Sync
isActive	true	Enabled

Empty Values

To set empty values (common for de-provisioning flows):

Destination Attribute	Formatter	Continuous Sync
manager_id	" "	Enabled
isActive	false	Enabled

Source of Identity Formatters

Target attributes can be updated based on attributes belonging to the source of identity. To reference the value of a source entity attribute, use the format {<source_attribute_name>}.

Examples:

Destination Attribute	Formatter Example	Continuous Sync
first_name	{first_name}	Enabled
last_name	{last_name}	Enabled
email	{first_name}.{last_name}@domain.com {first_name}_{last_name}@domain.com {last_name}@domain.com {firstname_initial}{last_name}@domain.com {firstname_initial}-{last_name}@domain.com {firstname_initial}{middlename_initial}{last_name}@domain.com {last_name}-{firstname_initial}@domain.com	-

Alias Definitions

Early Access: Alias Definitions is currently in early access. Contact your Veza representative to enable this feature for your tenant.

When to use aliases

By default, when you reference an attribute such as {department} in a formatter, the system searches through your configured identity sources in order (primary first, then secondary sources). This works well for simple policies with a single source of identity.

Aliases become useful when:

• Multiple integrations share the same entity type (e.g., two Active Directory instances, or when your source of identity and sync target use the same entity type)

• A policy involves multiple integrations that have attributes with the same name

• You need to explicitly control which system's attribute value is used

• You want to compare values between source and target systems while defining LCM Workflow Conditions

• You need to detect movers based on changes in a specific system

Alias Naming: The system automatically adds a $ prefix to all alias names. For example, if you create an alias named workday in the UI, it becomes $workday when used in formatters and conditions.

Example: HR System to Directory Sync

A policy syncs identities from an HR system (Workday) to a directory (Active Directory). Both have a department attribute. Without aliases, {department} resolves from whichever system appears first in the search order. With configured aliases hr and directory (which become $hr and $directory), you can explicitly reference {$hr.department} to ensure you're using the authoritative HR value.

Aliases can be used in:

• Attribute formatters

• Workflow trigger conditions

• Action conditions

• Mover property definitions

• Test formatters (for validation before deployment)

Configuring aliases

Aliases provide shorthand references to specific integrations and entity types, making transformers and conditions more readable in complex policies.

To configure aliases, open a Lifecycle Management policy, click Edit, and navigate to the Alias Definitions tab. Each alias requires:

• Alias Name: Must start with $ followed by at least one lowercase letter, number, or underscore. Additional $ characters can appear after the first character. The $ prefix is added automatically if omitted. Valid examples: $workday, $hr_system, $ad$corp. Invalid examples: $, $AD (uppercase), $$double (multiple leading $).

• Integration: The data source containing the entity type.

• Entity Type: The entity type to reference (e.g., WorkdayWorker, OktaUser).

Validation Rules: Alias names allow only lowercase alphanumeric characters, underscores, and $. They must start with exactly one $ (not zero, not multiple), and cannot be $target (reserved for action-level attribute references).

Testing and Validation: Aliases work in test formatters, allowing you to validate your formatter expressions before deployment. Additionally, alias-resolved attribute values appear in dry run results, so you can preview exactly which values will be synced.

Input and output resolution

Aliases can resolve attributes from two contexts:

• Input: Values from the source system before any sync action runs (the authoritative data)

• Output: Values currently in the target system (what's already provisioned)

By default, the system checks output first, then falls back to input. Use suffixes to explicitly control resolution:

Suffix	Resolves From	Example	Use Case
(none)	Output, then input	{$workday.department}	General attribute access
$in	Source only	{$workday$in.department}	Get the authoritative source value
$out	Target only	{$workday$out.department}	Get the current target value

When to Use Suffixes: Use $in when you need the authoritative value from the source system (e.g., HR system). Use $out when you need to compare against what's currently provisioned in the target. Without a suffix, the system checks the target first—useful when you want the most recent value regardless of source.

Comparison operators

Use these operators in IF conditions to compare attribute values:

Operator	Meaning	Supported Types
eq	Equals	Boolean, string, number, timestamp
ne	Not equals	Boolean, string, number, timestamp
co	Contains	String, string list
sw	Starts with	String
ew	Ends with	String
lt	Less than	Number, timestamp
le	Less than or equals	Number, timestamp
gt	Greater than	Number, timestamp
ge	Greater than or equals	Number, timestamp

Combine conditions with and, or, or negate with not.

String List Attributes: For multi-value attributes (string lists), only the co (contains) operator is supported. Use it to check if the list includes a specific value, for example: IF $workday.roles co "Manager".

Examples

In attribute formatters:

{$workday.first_name | LOWER}.{$workday.last_name | LOWER}@company.com

In LCM Workflow Conditions (comparing source and target values):

IF $workday$in.department ne $ad$out.department
  {$workday$in.department}
ELSE
  {$ad$out.department}

Multiple integrations with the same entity type:

For organizations with multiple Active Directory domains (e.g., corporate employees and contractors), you can create distinct aliases to control which AD integration is used:

• Configure alias corp_ad → Integration: AD_Corporate, Entity Type: ActiveDirectoryUser

• Configure alias contractor_ad → Integration: AD_Contractors, Entity Type: ActiveDirectoryUser

Then explicitly reference the correct domain in your formatters:

{$corp_ad.department}

This ensures you're using the department attribute from the corporate AD integration rather than the contractor AD integration, even though both use the same ActiveDirectoryUser entity type.

Transformation functions

Based on the user metadata available from your source of identity (SOI), you may need to convert a full email address to a valid username, standardize a date, or generate a unique identifier for users provisioned by Veza. Suppose an attribute value needs to be altered to be compatible with the target system. In that case, you can transform the value of a source attribute or apply a range of other functions to generate the target value.

Formatter expressions use the following syntax: {<source_attribute_name> | <FUNCTION_NAME>,<param1>,<param2>}

For example:

Destination Attribute	Formatter	Description	Example
username	`{email | REMOVE_DOMAIN}`	Removes the domain from the email to create username	"jsmith" is the output derived from [email protected]
user_id	`f{id | UPPER}`	Converts ID to uppercase	JSMITH" is the output derived from the userid, "jsmith"

Transformation function categories

Refer to the Transformer Reference page for complete documentation of all supported functions, parameters, and usage examples. The reference includes:

Category	Functions	Use Cases
String case	UPPER, LOWER, TITLE_CASE, SENTENCE_CASE, LOWER_CAMEL_CASE, UPPER_CAMEL_CASE, LOWER_SNAKE_CASE, UPPER_SNAKE_CASE	Standardize naming conventions
String manipulation	TRIM, TRIM_CHARS, REMOVE_CHARS, REMOVE_WHITESPACE, REPLACE_ALL, APPEND, PREPEND	Clean and format string data
Substring	FIRST_N, LAST_N, SUB_STRING, SPLIT	Extract portions of values
Padding	LEFT_PAD, RIGHT_PAD, ZERO_PAD	Create fixed-width identifiers
Date/time	DATE_FORMAT, DATE_ADJUST, DATE_ADJUST_DAY, ASSUME_TIME_ZONE, UTC_TO_TIME_ZONE, NOW	Convert and manipulate dates
Character encoding	ASCII, REMOVE_DIACRITICS	Handle international characters
Lookup	LOOKUP, FROM_ENTITY_ATTRIBUTE, FROM_MANY_ENTITIES_ATTRIBUTE	Cross-reference data from tables or entities
Generation	NEXT_NUMBER, UUID_GENERATOR, RANDOM_INTEGER, RANDOM_STRING_GENERATOR, RANDOM_ALPHANUMERIC_GENERATOR, RANDOM_NUMBER_GENERATOR	Create unique values
Domain	REMOVE_DOMAIN	Extract usernames from email addresses
Formatting	COUNTRY_CODE_ISO3166, LANGUAGE_RFC5646, PHONE_NUMBER_E164	Standardize to international formats

Contact Veza if you require additional transformations for your use case.

Pipeline Functions {#pipeline-functions}

You can pipeline multiple transformation functions together, separated by a vertical bar (|). Each will apply in sequence, allowing for complex attribute formatters that use the output of one function as the input of another.

Example Pipeline Functions

• {name | UPPER}

  • If name = Smith, the result is SMITH.

• {first_name | SUB_STRING,0,1 | LOWER}.{last_name | LOWER}

  • If first_name = John and last_name = Smith, the result is j.smith.

• {email | REMOVE_DOMAIN}

  • If email = [email protected], the result is john.smith.

• {email | REPLACE_ALL, " ", "."}

  • If email = john [email protected], the result is [email protected].

• {location | LOOKUP locationTable, location_code, city}

  • If location = IL001, the result is Chicago (using a lookup table named locationTable).

• {start_date | DATE_FORMAT, "01/02/2006" | UPPER}

  • If start_date = 2023-03-15, the result is 03/15/2023 (DATE_FORMAT doesn't typically need UPPER, but shows pipeline capability).

• {hire_date | DATE_FORMAT, "Jan 2, 2006" | REPLACE_ALL, " ", "_"}

  • If hire_date = 2023-03-15, the result is Mar_15,_2023.

• {office_code | TRIM_CHARS_LEFT, ".0" | TRIM_CHARS_RIGHT, ".USCA"}

  • If office_code = 000.8675309.USCA, the result is 8675309.

• {username | REMOVE_CHARS, ".-_" | TRIM | UPPER}

  • If username = "–john.doe_–", the result is JOHNDOE.

• {employee_id | REMOVE_CHARS, "#" | TRIM_CHARS, "0" | LEFT_PAD, 6, "0"}

  • If employee_id = "##001234##", the result is 001234.

• {department | REMOVE_WHITESPACE | LOWER | REPLACE_ALL, "&", "and"}

  • If department = "Sales & Marketing", the result is salesandmarketing.

• TEST{| RANDOM_INTEGER, 1000, 9999}

  • Generates test IDs like TEST4827, TEST8391 (see RANDOM_INTEGER for details).

Testing Transformers Inline

Before deploying transformers in production policies, you can validate formatter expressions directly in the Veza UI. This allows you to verify that your transformation logic produces the expected output without affecting live data.

Using the Test Interface

When adding or editing a transformer in a policy, look for the Test Formatter button next to the transformer field. Clicking it opens a test dialog:

1. Enter your transformer expression in the Attribute Transformer field

2. Click the Test Formatter button to open the test dialog

3. The dialog shows input fields for each attribute referenced in your expression (e.g., {first_name}, {email})

4. Enter sample values for each attribute

5. Click Test Formatter in the dialog to evaluate the expression

6. View the result to verify the transformation produces expected output

7. Click Save to close the dialog, or Cancel to discard changes

The test dialog is available wherever transformers are configured, including:

• Action synced attributes

• Unique identifiers

• Common transformers

• Date formatters

Testing Examples

Expression	Test Input	Expected Output
UPPER	john.doe	JOHN.DOE
{email | SPLIT("@") | INDEX(0)}	[email protected]	john.doe
{start_date | DATE_FORMAT("2006-01-02")}	2025-01-15T10:30:00Z	2025-01-15
{name | LOWER | REPLACE_ALL(" ", ".")}	John Smith	john.smith

Testing Pipeline Functions

For complex pipelines, test incrementally:

1. Test the first function alone to verify it handles the input correctly

2. Add each subsequent pipe and verify intermediate results

3. Validate the complete pipeline produces the final expected value

This step-by-step approach helps isolate issues when a transformation doesn't produce the expected output.

The test interface uses sample data you provide. Ensure your test values accurately represent the source attribute data types and formats you'll encounter in production.

When to Use Inline Testing vs. Dry Run

Scenario	Use
Validating a single transformer expression	Inline Testing
Testing how transformers work with real entity data	Dry Run
Verifying complete policy workflow execution	Dry Run

Use inline testing during transformer development, then validate the complete policy with a dry run before deploying to production.

Common Transformers

As part of implementing Lifecycle Management (LCM) processes with Veza, you should create sets of common transformers to define how values such as username, login, or ID are sourced for each LCM Policy. These transformers can then be reused across all identity sync and deprovision policy workflows.

Create common transformers to consistently form attributes for specific entity types, and reuse them to avoid errors and save time when creating actions for that entity type. The order of common transformers matters when multiple transformers set the same destination attribute. Drag-and-drop to reorder common transformers and control precedence.

For example, defining a common synced attribute to describe how to format Azure AD account names {username}@evergreentrucks.com enables reuse across multiple workflow actions. You can also define synced attributes at the action level when they are used only once within a policy, such as setting the primary group DN and OU of de-provisioned identities to a group reserved for terminated accounts.

Common Transformer Examples:

Transformer & Entity Type	Attribute	Value Format	Continuous Sync	Description
ADAccountTransformer ActiveDirectoryUser	account_name	{display_full_name}	No	Basic account name
	distinguished_name	CN={first_name} {last_name},OU={department},OU={location},DC=company,DC=local	Yes	Full AD path
	user_principal_name	`{first_name	SUB_STRING,0,1	LOWER}.{last_name
	email	{first_name}{last_name}@company.com	Yes	Email address
OktaAccountTransformer OktaUser	login	`{first_name	SUB_STRING,0,1	LOWER}.{last_name
	email	{first_name}{last_name}@company.com	Yes	Email address
	username_prefix	`{first_name	SUB_STRING,0,1	LOWER}.{last_name
AzureADTransformer AzureADUser	principal_name	{first_name}{last_name}	No	Primary identifier
	mail_nickname	`{first_name	SUB_STRING,0,1	LOWER}{last_name
	display_name	{first_name} {last_name}	Yes	Display name
GoogleAccountTransformer GoogleWorkspaceUser	email	{first_name}{last_name}@company.com	No	Primary email
	email_addresses	{username}@company.com	No	Email list
	recovery_email	{personal_email}	Yes	Backup email
ContractorTransformer ActiveDirectoryUser	account_name	c-{username}	No	Contractor prefix
	distinguished_name	CN={first_name} {last_name},OU=Contractors,OU={department},DC=company,DC=local	Yes	Contractor OU
	description	Contractor - {vendor_company} - Start Date: {start_date}	Yes	Metadata
RegionalEmailTransformer ExchangeUser	email_address	{username}@{region}.company.com	No	Regional email
	alias	{first_name}.{last_name}@{region}.company.com	Yes	Regional alias

$target Attribute Transformer Function

The $target attribute transformer function is used when a value consists of one or more attributes that require an operation(s), making it too complex to transform, but it needs to be reused.

Important: The $target function can only be used within the same Action.

For example, an email address consists of [email protected]. However, you must use the format [email protected]. By using the $target function, you reuse only one attribute, username, while not changing the other two attributes (firstname_lastname).

Example:

Destination Attribute

username

Formatter

`{firstname}{lastname}`

Formatter

`{$target.username}@sample.com`

Custom Attribute Transformer Function

The Custom Attribute Transformer function allows you to define a custom transformer that acts as an alias for applying one or more transformer functions.

For example, you can define a custom function named $CLEAN, which is used as {first_name | $CLEAN}. This function can consist of a series of transformer functions such as | ASCII | LOWER | REMOVE_CHAR |.

To define a custom attribute transformer, use the following guidelines:

Policy Version Definitions

• Custom functions must be defined as part of the policy version.

• These definitions are structured similarly to hard-coded definitions and are returned in the same format, allowing the Veza UI to handle them without modification.

• The API for updating and retrieving a policy version must also support these custom function definitions.

Naming Convention: Custom functions must be in ALL CAPS and prefixed with a $ to avoid conflicts with built-in functions.

Custom Attribute Transformer Limitations

The following custom definitions are not supported:

• Transformer functions with included transformer parameters

• Nested transformer functions

• Transformer functions with parameters

Appending Multi-Value Attribute (Active Directory only)

As part of the Identity Sync action, you can append values to multi-value Active Directory attributes without replacing existing values. This ensures that existing attribute values are preserved when adding new ones.

This feature is specific to Active Directory and is not available for other integrations.

Supported Multi-Value Attributes:

Active Directory supports appending for the following multi-value attributes:

• organizationalStatus, departmentNumber, employeeType

• servicePrincipalName, proxyAddresses

• member, memberOf, roleOccupant

• url, wWWHomePage

• otherTelephone, otherMobile, otherIpPhone, otherFacsimileTelephoneNumber, otherHomePhone, otherPager, otherMailbox

• And additional multi-value attributes including: objectClass, postalAddress, postOfficeBox, seeAlso, userCertificate, userSMIMECertificate, userPKCS12, securityIdentifierHistory, altSecurityIdentities, businessCategory, carLicense, homePostalAddress

Syntax:

Use the >> prefix before the array to append values:

>>[value1, value2, value3]

Appending syntax supports two array formats:

• With quotes (JSON format): >>[``"Active", "Permanent"]

• Without quotes (simple format): >>[Active, Permanent]

When you use this syntax:

1. New values are added to the end of the existing attribute values

2. Duplicate values are automatically removed

3. The order of existing values is preserved

4. New values appear after existing values in the order specified

For example, ff an Active Directory user has:

organizationalStatus: ["Active", "Employee"]

And you apply the transformer:

>>[Employee, Contractor, Temporary]

The resulting value is:

organizationalStatus: ["Active", "Employee", "Contractor", "Temporary"]

Note that "Employee" was already present and not duplicated.

Setting vs. Appending:

• To Replace existing values: Use [value1, value2] (without >>)

• To Append to existing values: Use >>[value1, value2] (with >>)

Additional Notes:

• The append prefix (>>) only works for multi-value attributes. It is ignored for single-value attributes

• If the attribute has no existing values, the values are simply set (no difference from non-append behavior)

• Both the appending syntax and the standard array syntax support arrays with or without quotes around values