Attribute Sync and Transformers

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

When creating workflows in Lifecycle Management policies to create, sync, or de-provision 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 from the source of identity, such as an identity provider, HR system, or CSV upload. Attributes can be synchronized once or kept in continuous sync as changes occur over the user’s lifetime.

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.

• 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: Mote a user’s Active Directory account to an OU reserved for terminated accounts.

When synchronizing a user’s attributes, Veza can apply one (or more) transformations to convert the source attribute values to a more suitable format, and apply the result within the target application as user account attribute.

For example, a transformer might remove the domain from an email address, replace special characters, or convert a string from upper case to lower case. Transformers can apply to any attribute on the target user account with the complexity varying depending on your business requirements.

See the following sections for more information about formatting destination attributes and possible transformations:

Continuous Sync

Continuous Sync keeps identity attributes in target systems up to date with your source of truth. It has three configuration levels that work together to determine how attributes are synchronized:

Workflow Level

The workflow's continuous sync setting controls change detection:

• When enabled: The workflow monitors for any changes in the source system

• When disabled: The workflow only runs during initial provisioning

Action Level

For Sync Identity actions, this controls whether existing entities can be updated:

• When enabled: The action can update existing entities

• When disabled: The action only sets attributes during initial creation

Attribute Level

Individual attributes can be configured for continuous sync:

• When enabled: The attribute will be updated when changes are detected

• When disabled: The attribute is only set during initial creation

All three levels must be enabled for an attribute to be continuously synchronized. For example, if you want to keep an employee's department updated:

1. Enable continuous sync on the workflow to monitor for changes

2. Enable continuous sync on the sync action to allow updates

3. Enable continuous sync on the department attribute transformer

Recommended Settings

Enable continuous sync for attributes that change during employment:

• Employee name

• Department

• Title

• Manager

• Cost Center

• AD Distinguished Name (DN)

• AD User Principal Name (UPN)

• AD Email

Disable continuous sync for stable identifiers:

• Active Directory sAMAccountName

• Email Addresses (for Email Write-Back action)

This configuration ensures that dynamic attributes stay updated while preserving stable identifiers.

Common Transformers

As part of implementing lifecycle management processes with Veza, you should create sets of common transformers to define how values such as username, login, or ID should be sourced for each target application. These transformers can then be reused across all identity sync and de-provision workflows involving those targets. Create common transformers to consistently form attributes for specific entity types, and re-use them to avoid errors and save time when creating actions for that entity type.

For instance, 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	{username}@company.com	Yes	UPN format
	email	{username}@company.com	Yes	Email address
OktaAccountTransformer OktaUser	login	{username}@company.com	No	Primary login
	email	{username}@company.com	Yes	Email address
	username_prefix	{first_name | SUB_STRING,0,1 | LOWER}{last_name | LOWER}	No	Username creation
AzureADTransformer AzureADUser	principal_name	{username}@company.com	No	Primary identifier
	mail_nickname	{first_name | SUB_STRING,0,1 | LOWER}{last_name | LOWER}	No	Email alias
	display_name	{first_name} {last_name}	Yes	Display name
GoogleAccountTransformer GoogleWorkspaceUser	email	{username}@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

Adding transformers

Transformers can be defined at the policy level or when configuring an individual action in a workflow. To configure a transformer, add basic details as well as how to source the value of each attribute:

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

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.

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

   2. Formatter: Choose how the destination attribute should be formatted. Specify the value, a {source_attribute}, or apply Transformation Functions.
   3. Pipeline Functions: Combine attribute formatters with the | character to apply more complex transformations, such as combining the first letter of a first_name and the first four characters of a last_name to generate a local username. See Pipeline Functions for more examples
   4. Continuous Sync: Enabling this option always syncs the attribute, whilst applying any defined transformations. By default, attributes will not sync if the target identity is already created.

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 according to a function, or some combination of the three.

Note that 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 over the user or account 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
active	true	Enabled

Empty Values

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

Destination Attribute	Formatter	Continuous Sync
manager_id	" "	Enabled
active	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	Continuous Sync
first_name	{first_name}	Enabled
last_name	{last_name}	Enabled
email	{first_name}.{last_name}@domain.com	-

Transformation functions

Based on the user metadata that is available from your source of identity, 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. If an attribute value needs to be altered for compatibility with the target system, 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
username	{email | REMOVE_DOMAIN}	Removes domain from email to create username
user_id	{id | UPPER}	Converts ID to uppercase

Table of transformation functions

See the table below for all supported functions and parameters. Some commonly used transformation functions include:

• Replacing a character with a different one

• Removing domains from email addresses

• Transforming to upper, lower, camel, or snake case

• Using a substring from the original value

Please contact Veza if additional transformations are required for your use case.

Function	Description	Parameters	Requires Input	Returns Multiple	Example
COUNTRY_CODE_ISO3166	Transforms country code to ISO 3166 format.	Format (STRING, optional): [alpha2, alpha3, numeric], defaults to alpha2	Yes	No	COUNTRY_CODE_ISO3166("US", alpha3) results in USA
DATE_FORMAT	Transforms dates to a different format.	Output (STRING, required): Format of returned value. Input (STRING, optional): Format of input	Yes	No	DATE_FORMAT("2021-01-01", "MM/DD/YYYY") results in 01/01/2021
FIRST_N	Picks the first N characters of a string.	Length (NUMBER, required): Number of characters to return	Yes	No	FIRST_N("first_name", 4) results in firs
FROM_ENTITY_ATTRIBUTE	Transforms a string from an attribute of another entity in the graph.	EntityType (STRING, required), SourceAttribute (STRING, required), TargetAttribute (STRING, required)	Yes	No	FROM_ENTITY_ATTRIBUTE("Employee", "ID", "ManagerID") results in the Manager ID for the employee
LANGUAGE_RFC5646	Transforms language to RFC 5646 format.	None	Yes	No	LANGUAGE_RFC5646("Spanish") results in es
LAST_N	Picks the last N characters of a string.	Length (NUMBER, required): Number of characters to return	Yes	No	LAST_N("last_name", 5) results in name
LEFT_PAD	Left pads a string with a character.	Length (NUMBER, required), Pad (CHARACTER, optional): Default is space	Yes	No	LEFT_PAD("123", 5, "0") results in 00123
LOWER	Transforms string to lowercase.	None	Yes	No	LOWER("HELLO") results in hello
LOWER_CAMEL_CASE	Transforms string to lower camel case.	None	Yes	No	LOWER_CAMEL_CASE("hello world") results in helloWorld
LOWER_SNAKE_CASE	Transforms string to lowercase with underscores.	None	Yes	No	LOWER_SNAKE_CASE("Hello World") results in hello_world
NEXT_NUMBER	Generates a set of integers as strings.	BeginInteger (NUMBER, required), Length (NUMBER, required)	No	Yes	NEXT_NUMBER(5, 3) results in 5, 6, 7
PHONE_NUMBER_E164	Transforms phone number to E.164 format.	Region (STRING, optional): ISO 3166-1 alpha-2 format	Yes	No	PHONE_NUMBER_E164("[phone]") results in [phone]
RANDOM_ALPHANUMERIC_GENERATOR	Generates a random alphanumeric string.	Length (NUMBER, required)	No	No	RANDOM_ALPHANUMERIC_GENERATOR(8) results in a1B2c3D4
RANDOM_NUMBER_GENERATOR	Generates a random number string.	Length (NUMBER, required)	No	No	RANDOM_NUMBER_GENERATOR(4) results in 4829
RANDOM_STRING_GENERATOR	Generates a random string.	Length (NUMBER, required)	No	No	RANDOM_STRING_GENERATOR(6) results in uFkLxw
REMOVE_DIACRITICS	Removes diacritics (accents, etc.) from input string.	None	Yes	No	REMOVE_DIACRITICS("José") results in Jose
ASCII	Removes non-printable characters and replaces non-ASCII characters with their closest ASCII equivalents.	None	Yes	No	ASCII("Łukasz Gruba") results in Lukasz Gruba
REMOVE_DOMAIN	Removes the domain from an email.	None	Yes	No	REMOVE_DOMAIN("[e-mail]") results in user
REPLACE_ALL	Replaces all instances of one string with another.	Original (STRING, required), New (STRING, required)	Yes	No	REPLACE_ALL("hello world", " ", "_") results in hello_world
RIGHT_PAD	Right pads a string with a character.	Length (NUMBER, required), Pad (CHARACTER, optional): Default is space	Yes	No	RIGHT_PAD("123", 5, "0") results in 12300
SPLIT	Splits a string and returns the string at the given index.	Split String (STRING, required), Index (NUMBER, required)	Yes	No	SPLIT("[e-mail]", "@", 0) results in first.last
SUB_STRING	Picks a substring from the original value.	Offset (NUMBER, required), Length (NUMBER, required)	Yes	No	SUB_STRING("hello", 0, 3) results in hel
TRIM	Removes spaces before and after a string.	None	Yes	No	TRIM(" hello ") results in hello
UPPER	Transforms string to uppercase.	None	Yes	No	UPPER("hello") results in HELLO
UPPER_CAMEL_CASE	Transforms string to upper camel case.	None	Yes	No	UPPER_CAMEL_CASE("hello world") results in HelloWorld
UPPER_SNAKE_CASE	Transforms string to uppercase with underscores.	None	Yes	No	UPPER_SNAKE_CASE("hello world") results in HELLO_WORLD
UUID_GENERATOR	Generates a UUID.	None	No	No	UUID_GENERATOR() results in 123e4567-e89b-12d3-a456-426614174000
LOOKUP	Transforms a value using a lookup table.	Table Name (STRING, required), Column Name (STRING, required), Return Column Name (STRING, required)	Yes	No	LOOKUP("IL001", "locationTable", "location_code", "city") results in Chicago

Using the ASCII Transformer

The ASCII transformer is particularly useful when working with international user data or systems that have strict character limitations. This transformer performs two main operations:

1. Removes all non-printable characters (including control codes, zero-width spaces, tabs, and newlines)

2. Converts non-ASCII characters to their closest ASCII equivalents

Whereas the REMOVE_DIACRITICS transformer only removes accent marks while preserving the basic character, the ASCII transformer performs a more comprehensive conversion, replacing characters like "Ł" with "L" and handling a wider range of non-ASCII characters.

Pipeline Functions

You can pipeline multiple transformation functions together, separated by a |. 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 = [e-mail], the result is john.smith.

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

  • If email = john [e-mail], the result is [e-mail].

• {location | LOOKUP locationTable, location_code, city}

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

Further reference

• Actions: Manage Relationships