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 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 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 employment lifecycle.

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 the following sections for more information about formatting destination attributes and possible transformations:

Continuous Sync

Continuous Sync ensures that identity attributes in target systems remain up-to-date with the corresponding attributes residing at the 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

You may not want to enable continuous sync at the Attribute level when there is a change in the user principal name, such as a change in marital status or legal name correction.

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:

Enable continuous sync on the workflow to monitor for changes
Enable continuous sync on the sync action to allow updates
Enable continuous sync on the department attribute transformer

Recommended Settings

Enable continuous sync for attributes that change during employment:

First Name Surname
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.

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:

Assign a name and description to the transformer, and specify the data source to which it applies.
Entity Type: Choose the target entity type in the destination system.
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

{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 {firstname_initial}-{last_name}[email protected] {last_name}-{firstname_initial}@domain.com

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 for compatibility 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"

Table of transformation functions

Refer to the table below for a comprehensive list of 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

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

Function

Description

Parameter Format

Example

ASCII

Removes non-printable characters and replaces non-ASCII characters with their closest ASCII equivalents.

Note: The ASCII transformer performs operations on the base level, not the extended set.

Characters (STRING, required)

{firstname | ASCII, "Łukasz Gruba"}

results in Lukasz Gruba

COUNTRY_CODE_ISO3166

Transforms country code to ISO 3166 format.

ISO 3166 defines codes for the representation of country names, dependent territories, and their subdivisions.

Format (STRING, optional): [alpha2, alpha3, numeric], defaults to alpha2

{COUNTRY_CODE_ISO3166, “US”, alpha3} results in USA

DATE_FORMAT

Transforms dates to a different format using Go time layout syntax.

Output Layout (STRING, required): Go time layout for output format. Input Layout (STRING, optional): Go time layout for input format

`{start_date | DATE_FORMAT, "01/02/2006"}`

formats date as MM/DD/YYYY

FIRST_N

Picks the first N characters of a string.

Characters (STRING, required)

Length (NUMBER, required): Number of characters to return

{FIRST_N, “world”, 4}

results in worl (the first four characters of the string)

FROM_ENTITY_ATTRIBUTE

Transforms a string from an attribute of another entity in the graph.

EntityType (STRING, required)

SourceAttribute (STRING, required), TargetAttribute (STRING, required)

{FROM_ENTITY_ATTRIBUTE, “Employee”, “ID”, “ManagerID”}

results in the Manager ID for the employee

LANGUAGE_RFC5646

Transforms language to RFC 5646 format.

RFC 5646 defines “Tags for Identifying Languages.” It does not contain a fixed, exhaustive list of language codes within the RFC itself. Instead, it specifies the structure and rules for constructing language tags, which are then built using codes from various external standards and registries.

Characters (STRING, required): Sting of a language name

{LANGUAGE_RFC5646, “Spanish”}

results in es

LAST_N

Picks the last N characters of a string, where N is the number of characters to return

Length (NUMBER, required)

{LAST_N, "helloworld, 5}

results in world

LEFT_PAD

Left pads a string with a character.

Length (NUMBER, required), Pad (CHARACTER, optional): Default is space

{LEFT_PAD, “123”, 5, “0”}

results in 00123

LOOKUP

Transforms a value using a lookup table.

Table Name (STRING, required), Column Name (STRING, required), Return Column Name (STRING, required)

{LOOKUP, “IL001”, “locationTable”, “location_code”, “city”}

results in Chicago

LOWER

Transforms all upper-case characters in a string to lower-case characters

Characters (STRING, required)

{LOWER, “HELLO”}

results in hello

LOWER_CAMEL_CASE

Transforms the first characters of a string to be converted to lower-case characters for camel case

Characters (STRING, required)

{LOWER_CAMEL_CASE, “hello world”}

results in helloWorld

LOWER_SNAKE_CASE

Transforms string to lowercase with underscores.

Characters (STRING, required)

{LOWER_SNAKE_CASE, “Hello World”}

results in hello_world

NEXT_NUMBER

Generates a set of integers as strings.

Integer (NUMBER, required), Length (NUMBER, required)

{NEXT_NUMBER, 2, 3}

results in “”, “2”, “3”, “4”.

Note: NEXT_NUMBER can also be used within IF/ELSE conditional transformers for intelligent username generation with automatic fallback strategies.

PHONE_NUMBER_E164

Transforms a phone number into the E.164 format.

E. 164 numbers are formatted [+] [country code] [subscriber number including area code] and can have a maximum of fifteen digits.

Region (STRING, optional): ISO 3166-1 alpha-2 format

{PHONE_NUMBER_E164, “+1-800-555-1212”}

results in +18005551212

RANDOM_ALPHANUMERIC_GENERATOR

Generates a random alphanumeric string.

Length (NUMBER, required)

{RANDOM_ALPHANUMERIC_GENERATOR, 8}

results in a1B2c3D4 (with eight characters)

RANDOM_NUMBER_GENERATOR

Generates a random number string.

Length (NUMBER, required)

{RANDOM_NUMBER_GENERATOR, 4}

results in 4829 (with four characters)

RANDOM_STRING_GENERATOR

Generates a random string.

Length (NUMBER, required)

{RANDOM_STRING_GENERATOR, 6}

results in uFkLxw (with six characters)

REMOVE_CHARS

Removes all instances of specified characters from a string.

Characters (STRING, required): Characters to be removed

{REMOVE_CHARS, "[email protected]", “@” “.”}

results in FirstLastexamplecom

REMOVE_DIACRITICS

Removes diacritics (accents, etc.) from input string.

Characters (STRING, required)

{REMOVE_DIACRITICS, “José”}

results in Jose

REMOVE_DOMAIN

Removes the domain from an email.

Characters (STRING, required)

{REMOVE_DOMAIN, "[email protected]"}

results in user

REMOVE_WHITESPACE

Removes all whitespace characters from a string.

Characters (STRING, required)

{REMOVE_WHITESPACE, “First Last”}

results in FirstLast

REPLACE_ALL

Replaces all instances of one string with another.

Original (STRING, required), New (STRING, required)

{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

{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)

{SPLIT, "[email protected]", "@", 0}

results in first.last where the index starts at 0

SUB_STRING

Picks a substring from the original value.

Offset (NUMBER, required), Length (NUMBER, required)

{SUB_STRING, “hello”, 0, 3}

results in hel

TRIM

Removes any white spaces before and after a string.

Characters (STRING, required)

{TRIM, " hello "}

results in hello

TRIM_CHARS

Removes all specified characters from the beginning and end of a string.

Characters (STRING, required): Characters to be trimmed

{TRIM_CHARS, “…first.last----”, “.-”}

results in first.last

TRIM_CHARS_LEFT

Removes all specified characters from the beginning of a string.

Characters (STRING, required): Characters to be trimmed from the left

{TRIM_CHARS_LEFT, “…first.last----”, “.-”}

results in first.last----

TRIM_CHARS_RIGHT

Removes all specified characters from the end of a string.

Characters (STRING, required): Characters to be trimmed from the right

{TRIM_CHARS_RIGHT, “…first.last----”, “.-”}

results in …first.last

UPPER

Transforms string to uppercase.

Characters (STRING, required): All lower-case characters to be converted to upper-case characters

{UPPER, “hello”}

results in HELLO

UPPER_CAMEL_CASE

Transforms string to upper camel case.

Characters (STRING, required): First characters of a string to be converted to upper-case characters for camel case

{UPPER_CAMEL_CASE, “hello world”}

results in Hello World

UPPER_SNAKE_CASE

Transforms string to uppercase with underscores.

Characters (STRING, required): All lower-case characters to be converted to upper-case characters with an underscore between strings

{UPPER_SNAKE_CASE, “hello world”}

results in HELLO_WORLD

UUID_GENERATOR

Generates a UUID. A UUID (Universally Unique Identifier) is a 128-bit identifier used to uniquely identify information in computer systems.

None

{UUID_GENERATOR}

results in 123e4567-e89b-12d3-a456-426614174000

DATE_ADJUST_DAY

Adjusts date value based on hour, day, month, year inputs provided (example: 2021-01-01 00:00:00 with a DATE_ADJUST of “+1,2,3,-1” becomes “2020-04-03 01:00:00”).

Integer - date Integer - hour Integer - day Integer - month Integer-year String (Optional) - Format

{activation_date | {DATE_ADJUST,+1,2,3,-1}
{activation_date | DATE_ADJUST,+1,2,3,-1, "RFC3339"}
{activation_date | DATE_ADJUST,+1,2,3,-1, "2006-01-02T15:04:05Z07:00"}

DATE_ADJUST

Adjusts date value based on the day input provided (example: 2021-01-01 00:00:00 with a DATE_ADJUST_DAY of “1” becomes “2021-01-02 00:00:00”).

Integer - date Integer - day String (Optional) - Format

{activation_date | DATE_ADJUST_DAY,+1}
{activation_date | DATE_ADJUST_DAY,+1,"RFC3339"}
{activation_date | DATE_ADJUST_DAY,+1,"2006-01-02T15:04:05Z07:00"}

NOW

Returns the current time in UTC. An optional argument indicates the outgoing time format; by default, the RFC3339 format.

String (Optional) - Format

{NOW}
{NOW, | "RFC3339"
{NOW, | "2006-01-02T15:04:05Z07:00"}

ASSUME_TIME_ZONE

Interprets the incoming time string as if it were in the specified time zone, then converts it to a UTC time. (example: if the input is “1/2/2025 11pm” and the defined time zone is “America/Los_Angeles” the function will treat “1/2/2025 11pm” as local time in Los Angeles and output the corresponding UTC time “1/3/2025 7am”)

String - Time Zone String (Optional) - Format

{activation_date | ASSUME_TIME_ZONE, "America/Los_Angeles"}
{activation_date | ASSUME_TIME_ZONE, "America/Los_Angeles", "RFC3339"}
{activation_date | ASSUME_TIME_ZONE, "-07:00"}
{activation_date | ASSUME_TIME_ZONE, "-07:00", "RFC3339"}

UTC_TO_TIME_ZONE

Interprets the incoming time string as if it were in UTC and then converts it to the specified time zone. (example: if the input is “1/2/2025 11pm” and the specified time zone is “America/Los_Angeles” the function will treat “1/2/2025 11pm” as the UTC time zone and output the corresponding “America/Los_Angeles” time “1/2/2025 3pm”) Note: When using the time zone parameter, a named time zone (“America/Los_Angeles”) accounts for daylight saving time, whereas a time zone offset ("-07:00") is always calculated from UTC, ignoring daylight saving time.

String - Time Zone String (Optional) - Format

{activation_date | UTC_TO_TIME_ZONE, "America/Los_Angeles"}
{activation_date | UTC_TO_TIME_ZONE, "America/Los_Angeles", "RFC3339"}
{activation_date | UTC_TO_TIME_ZONE, "-07:00"}
{activation_date | UTC_TO_TIME_ZONE, "-07:00", "RFC3339"}

Using the ASCII Transformer

The ASCII transformer is particularly useful when working with localized user data and legacy systems that have strict character set limitations (such as Active Directory sAMAccountName restrictions). This transformer performs two primary operations:

Removes all non-printable ASCII characters (including control codes, zero-width spaces, tabs, and newlines)
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, including the following:

Accented Letters: Letters with diacritics like é, à, ö, ñ, ç, etc., commonly used in languages like French, Spanish, German, and Portuguese. Non-Latin Alphabets: Characters from various alphabets such as Cyrillic (e.g., ж, б), Greek (e.g., α, β), Arabic (e.g., ح, ص), Hebrew, and Chinese (e.g., 汉, 字). Mathematical and Technical Symbols: Symbols like infinity (∞), integral (∫), summation (∑), Ohm (Ω), degree (°). Currency Symbols: Symbols like €, £, ¥. Emoji: Various emoticons like 😊, 😞, etc. Other Symbols: Symbols like ©, ®, ™, etc.

DATE_FORMAT Transformer using Date Strings

The DATE_FORMAT transformer formats date strings using Go time package layout syntax. This transformer helps convert between different date formats, such as transforming dates for LDAP integration or standardizing date formats across systems.

Go Time Layout Syntax

Go time layouts use a specific reference time: Monday, January 2, 15:04:05 MST 2006, which is Unix time 1136239445. All layout strings must use the exact digits and format from this reference time. For more information about Go time layouts, refer to the official Go time package documentation. Date Components:

2006 = 4-digit year
06 = 2-digit year
01 = 2-digit month (01-12)
1 = 1-digit month (1-12)
Jan = 3-letter month abbreviation
January = full month name
02 = 2-digit day (01-31)
2 = 1-digit day (1-31)
_2 = space-padded day
DateTime = “2006-01-02 15:04:05”
DateOnly = “2006-01-02”

Time Components:

15 = 24-hour format hour (00-23)
03 = 12-hour format hour (01-12)
3 = 12-hour format hour without leading zero (1-12)
04 = minute (00-59)
4 = minute without leading zero (0-59)
05 = second (00-59)
5 = second without leading zero (0-59)
PM = AM/PM indicator
pm = am/pm indicator (lowercase)
TimeOnly = “15:04:05”

Weekday Components:

Mon = 3-letter weekday abbreviation
Monday = full weekday name

Time Zone Components:

MST = time zone abbreviation
Z0700 = RFC3339 time zone format
Z07:00 = RFC3339 time zone format with colon

RFC Components:

RFC822 = “02 Jan 06 15:04 MST”
RFC822Z = “02 Jan 06 15:04 -0700” // RFC822 with numeric zone
RFC850 = “Monday, 02-Jan-06 15:04:05 MST”
RFC1123 = “Mon, 02 Jan 2006 15:04:05 MST”
RFC1123Z = “Mon, 02 Jan 2006 15:04:05 -0700” // RFC1123 with numeric zone
RFC3339 = “2006-01-02T15:04:05Z07:00”
RFC3339Nano = “2006-01-02T15:04:05.999999999Z07:00”

Other Constant Components:

Layout = “01/02 03:04:05PM '06 -0700” // The reference time, in numerical order.
ANSIC = “Mon Jan _2 15:04:05 2006”
UnixDate = “Mon Jan _2 15:04:05 MST 2006”
RubyDate = “Mon Jan 02 15:04:05 -0700 2006”
Kitchen = “3:04PM” // Handy time stamps.
Stamp = “Jan _2 15:04:05”
StampMilli = “Jan _2 15:04:05.000”
StampMicro = “Jan _2 15:04:05.000000”
StampNano = “Jan _2 15:04:05.000000000”

Common Layout Examples

Layout String

Format

Example Output

01/02/2006

MM/DD/YYYY

03/15/2023

2006-01-02

YYYY-MM-DD

2023-03-15

02-Jan-2006

DD-MMM-YYYY

15-Mar-2023

Jan 2, 2006

MMM D, YYYY

Mar 15, 2023

Monday, January 2, 2006

Full date

Wednesday, March 15, 2023

2006-01-02 15:04:05

Full timestamp

2023-03-15 14:30:25

03:04:05 PM

12-hour time

02:30:25 PM

15:04

24-hour time

14:30

20060102150405Z

LDAP Z time format

20230315143025Z

Usage Examples

Basic Date Formatting:

`{start_date | DATE_FORMAT, "01/02/2006"}`

Formats any recognized date input into MM/DD/YYYY format.

Converting Between Specific Formats:

`{hire_date | DATE_FORMAT, "2006-01-02", "01/02/2006"}`

Parses input in MM/DD/YYYY format and outputs in YYYY-MM-DD format.

LDAP Integration Example: The DATE_FORMAT transformer was specifically enhanced to support LDAP Z and Win32 time format requirements.

The Z time format (20060102150405Z) is commonly used in LDAP directories and represents timestamps in UTC with a ‘Z’ suffix indicating zero UTC offset.

`{timestamp | DATE_FORMAT, "20060102150405Z"}`

Converts a date to LDAP Z time format for directory integration. Example for LDAP account expiration:

`{account_expires | DATE_FORMAT, "20060102150405Z"}`

Human-Readable Format:

`{event_date | DATE_FORMAT, "Monday, January 2, 2006"}`

Outputs a full, human-readable date format. Time Zone Handling:

{utc_time | DATE_FORMAT, "2006-01-02 15:04:05 MST"}

Includes time zone information in the output.

Additionally, the DATE_FORMAT transformer supports LDAP time format requirements using the format Win32 in LDAP directories:

{timestamp | DATE_FORMAT, "Win32"}

Converts a date to LDAP time format for directory integration.

Notes on DATE_FORMAT Transformers

Input Format: When the second parameter (input layout) is omitted, the transformer attempts to parse the input using common date formats automatically
Case Sensitivity: Layout components are case-sensitive (e.g., PM vs pm)
Leading Zeros: Use 01, 02, etc. for zero-padded values, and 1, 2, etc. for non-padded values
Reference Time: All layouts must use the exact reference time digits: Mon Jan 2 15:04:05 MST 2006

DATE_FORMAT Transformer using Time String (Generalized-Time)

The DATE_FORMAT transformer is used for formatting time using a time string to store time values in Generalized-Time format, which is required for Active Directory and other Microsoft-based target applications.

The Generalized-Time syntax is “YYYYMMDDHHMMSS.0Z”. Time String Format Example:

{date | DATE_FORMAT, "20010928060000.0Z"}

The “Z” indicates no time differential. Active Directory stores date/time as Greenwich Mean Time (GMT). If no time differential is specified, GMT is the default.

If the time is specified in a time zone other than GMT, the differential between the time zone and GMT is appended to the string instead of “Z” in the form “YYYYMMDDHHMMSS.0[+/-]HHMM”. Time Zone Format Example:

{date | DATE_FORMAT, "20010928060000.0+0200"}

The differential is based on the formula: GMT = Local + Differential.

String Manipulation Transformers

These transformers enable the cleaning, formatting, and standardization of string data from your source systems.

REMOVE_CHARS

The REMOVE_CHARS transformer removes all instances of specified characters from a string. This is useful for cleaning up data by removing unwanted punctuation, special characters, or formatting elements. Use Cases:

User ID creation: {email | REMOVE_CHARS, “-”}
- If email is "[email protected]", the result is “johndoe@examplecom”
Phone number formatting: {phone_number | REMOVE_CHARS, "()- "}
- If phone_number is “(123) 456-7890”, the result is “1234567890”
Cleaning account names: {account_name | REMOVE_CHARS, “!@#$%”}
- Removes special characters that might cause issues in target systems

REMOVE_WHITESPACE

The REMOVE_WHITESPACE transformer removes all whitespace characters (spaces, tabs, newlines) from a string. It can help create compact identifiers or ensure data consistency. Use Cases:

Username generation: {display_name | REMOVE_WHITESPACE}
- If display_name is “John A. Doe”, the result is “JohnA.Doe”
Tag creation: {department | REMOVE_WHITESPACE | LOWER}
- If the department is “Human Resources”, the result is “humanresources”
Creating system identifiers: {cost_center | REMOVE_WHITESPACE}
- Ensures cost center codes have no embedded spaces

TRIM, TRIM_CHARS, TRIM_CHARS_LEFT, and TRIM_CHARS_RIGHT

These transformers help clean up strings by removing unwanted characters from the beginning and/or end of strings. This is essential for data hygiene and ensuring consistent formatting. TRIM: Removes leading and trailing whitespace

Basic cleanup: {display_name | TRIM}
- If display_name is " John Doe ", the result is “John Doe”

TRIM_CHARS: Removes specified characters from both ends

Cleaning employee IDs: {employee_id | TRIM_CHARS, “0.”}
- If employee_id is “000.123.000”, the result is “123”
Removing padding characters: {code | TRIM_CHARS, “-_”}
- If code is “—ABC123___”, the result is “ABC123”

TRIM_CHARS_LEFT: Removes specified characters from the beginning only

Removing leading zeros: {cost_center | TRIM_CHARS_LEFT, “0”}
- If cost_center is “00012345”, the result is “12345”
Cleaning prefixes: {identifier | TRIM_CHARS_LEFT, “x”}
- If identifier is “xxxABC123”, the result is “ABC123”

TRIM_CHARS_RIGHT: Removes specified characters from the end only

Removing trailing characters: {office_code | TRIM_CHARS_RIGHT, “0”}
- If office_code is “ABC12300”, the result is “ABC123”
Cleaning suffixes: {code | TRIM_CHARS_RIGHT, “temp”}
- If code is “ABC123temp”, the result is “ABC123”

Advanced Conditional Logic with NEXT_NUMBER

The NEXT_NUMBER transformer can be combined with IF/ELSE conditional logic to create intelligent username generation with automatic fallback strategies. This is particularly useful for handling length constraints and ensuring unique usernames in Lifecycle Management attribute transformers.

Only one NEXT_NUMBER transformer can be used per transformation expression
The first alternative uses an empty string (""), followed by numbered alternatives (“2”, “3”, etc.)
Alternative values are automatically generated to ensure username uniqueness

Username Generation with Length-Based Fallbacks

This example creates usernames that adapt based on length constraints, using the sys_attr__would_be_value_len system attribute to evaluate the length of the generated value:

IF sys_attr__would_be_value_len le 20
  {first_name | LOWER}.{last_name | LOWER | NEXT_NUMBER, 2, 3}
ELSE IF sys_attr__would_be_value_len le 30
  {first_name | LOWER}.{last_name | LOWER | FIRST_N, 1 | NEXT_NUMBER, 2, 3}
ELSE
  {first_name | LOWER | FIRST_N, 1}.{last_name | LOWER | FIRST_N, 1 | NEXT_NUMBER, 2, 3}

Example outputs: For a user named “John Whitaker” (short enough for the first condition):

Base value: john.whitaker
Alternatives: john.whitaker2, john.whitaker3, john.whitaker4

For a user named “Leonevenkataramanathan Foster” (requires truncation to meet length limits):

Base value: l.f
Alternatives: l.f2, l.f3, l.f4

This approach ensures that username generation adapts to different name lengths while maintaining consistency and uniqueness across your identity management system.

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.

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. 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.

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}

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 | LOWER}

SUB_STRING,0,1

LOWER}.{last_name

{first_name}{last_name}@company.com

Yes

Email address

OktaAccountTransformer OktaUser

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

SUB_STRING,0,1

LOWER}{last_name

{first_name}{last_name}@company.com

Yes

Email address

username_prefix

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

SUB_STRING,0,1

LOWER}{last_name

AzureADTransformer AzureADUser

principal_name

{first_name}{last_name}

Primary identifier

mail_nickname

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

SUB_STRING,0,1

LOWER}{last_name

display_name

{first_name} {last_name}

Yes

Display name

GoogleAccountTransformer GoogleWorkspaceUser

{first_name}{last_name}@company.com

Primary email

email_addresses

{username}@company.com

Email list

recovery_email

{personal_email}

Yes

Backup email

ContractorTransformer ActiveDirectoryUser

account_name

c-{username}

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

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 are required to 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.

PreviousConditions and Actions NextFallback Formatters

Last updated 3 days ago

Was this helpful?