Overview

System attributes are computed properties that Lifecycle Management automatically generates during identity processing. These attributes enable advanced automation scenarios by providing runtime information about identity changes and transformation results.

All system attributes follow the sys_attr__ prefix convention and cannot be manually set or modified.

Available System Attributes

sys_attr__is_mover

A persistent boolean attribute that indicates whether an identity has undergone changes to monitored properties.

Type: Boolean Persistence: Stored with identity record Available in: Workflow triggers, conditions, and transformers

Configuration: Define monitored properties in the policy configuration:

Workflow Trigger Example:

Combined Condition Example:

The attribute is automatically set to true when any property in mover_properties changes during identity update. It is cleared when the identity is unchanged in an extraction cycle, and excluded from change detection to prevent recursive updates.

System attribute names are case-sensitive and must be lowercase in all expressions.

sys_attr__would_be_value

A transient attribute that provides a preview of the transformation result during conditional evaluation.

Type: String Persistence: Transient (exists only during IF statement evaluation) Available in: Conditional transformers only

Usage Example - Conditional Domain Addition:

The above transformer will check if the transformed email already contains "@", preserve existing email addresses, and add domain only when needed.

sys_attr__would_be_value_len

A transient attribute that provides the character length of the transformation result during conditional evaluation.

Type: Number Persistence: Transient (exists only during IF statement evaluation) Available in: Conditional transformers only

Usage Example - Progressive Username Truncation:

For "Leonevenkataramanathan Foster":

• First check (≤30 chars): leonevenkataramanathan.foster (30 chars - passes first condition)

• If >30 chars, second check (≤20 chars): leonevenkataramana.foster (25 chars - fails second condition)

• If >20 chars, fallback: l.f (3 chars - always succeeds)

Integration with NEXT_NUMBER

Preview attributes work with the NEXT_NUMBER transformer for generating unique alternatives:

This evaluates the base value length before applying numbering, ensuring the final result (including numbers) meets constraints.

Only one NEXT_NUMBER transformer is allowed per conditional branch.

Workflow Trigger Properties

The sys_attr__is_mover attribute supports additional trigger properties for fine-grained control:

This workflow triggers only when:

• The identity is marked as a mover (department or location changed)

• The identity is active

• At least one of the trigger_properties has changed since last extraction

Performance Notes

• Mover Detection: Comparison occurs for all properties in mover_properties during each extraction

• Preview Evaluation: Each IF branch with preview attributes requires transformation execution

• Optimization: Place most common conditions first to minimize preview evaluations

See Also

• - Complete list of transformation functions

• - Attribute transformation concepts and examples

• - Configuring mover properties and workflows

Overview

Fallback formatters can help resolve conflicts when provisioning identities with unique attributes. This is particularly useful when automated provisioning requires unique identifiers, but the standard generated values are already in use.

Understanding Fallback Formatters

When provisioning new identities through Lifecycle Management, unique attributes like usernames, login IDs, or email addresses must not conflict with existing values. Fallback formatters provide an automated way to generate alternative values when conflicts arise, ensuring provisioning can proceed without manual intervention.

You can configure fallback formatters when configuring a to ensure new users can be onboarded efficiently, regardless of naming conflicts.

Use Case: Username Conflicts

The most common use case for fallback formatters is handling username conflicts. For example:

Your organization uses a standard username format of first initial + last name (e.g., jsmith for John Smith).

When multiple employees have similar names, this can lead to conflicts:

• John Smith already has jsmith

• Jane Smith already has jsmith1

• James Smith already has jsmith2

When Jennifer Smith joins, the fallback formatter automatically assigns jsmith3, maintaining your naming convention while ensuring uniqueness.

Configuring Fallback Formatters

Fallback formatters can be configured as part of the "Sync Identities" action within a Lifecycle Management workflow:

1. Edit or create a Lifecycle Management policy

2. Edit the workflow containing the Sync Identities action

3. In the Sync Identities action configuration, click Add Fallback

4. Configure the to use as a fallback pattern for the unique attribute that might experience conflicts

Transformer Options for Fallback Formatters

Several transformers can be used for implementing fallback formatters depending on your specific use case.

Using the NEXT_NUMBER Transformer

A typical approach is to use the NEXT_NUMBER transformer, which is specifically designed to generate sequential numerical alternatives when naming conflicts occur.

The NEXT_NUMBER transformer:

• Generates a set of sequential integers as strings

• Takes two parameters: BeginInteger (starting number) and Length (how many numbers to generate)

• Is unique among transformers in that it returns multiple values, making it ideal for fallback scenarios

Other Useful Transformers for Fallbacks

In addition to NEXT_NUMBER, other transformers can be valuable for creating fallback formatters:

Using Random Alphanumeric for Unique Usernames:

This could generate usernames like jsmith8f3d instead of sequential jsmith1, jsmith2, etc.

Using UUID for Guaranteed Uniqueness:

This would append the first 8 characters of a UUID, creating identifiers like jsmith-a7f3e9c2.

Implementation Example

When configuring a fallback formatter with the NEXT_NUMBER transformer:

1. Select the attribute that requires uniqueness (e.g., username, email)

2. Configure the primary pattern (e.g., {first_initial}{last_name})

3. Add a fallback using the NEXT_NUMBER transformer to generate sequential alternatives:

This will generate up to 10 alternatives: jsmith1, jsmith2, ... jsmith10

Common Fallback Patterns

Here are some commonly used fallback patterns:

How Fallback Resolution Works

When Lifecycle Management attempts to provision a new identity with a unique attribute value that already exists:

1. The system first tries the primary format (e.g., jsmith)

2. If a conflict is detected, it automatically tries the first alternative using the NEXT_NUMBER transformer (e.g., jsmith1)

3. If that value also exists, it tries the next alternative (e.g., jsmith2)

This automated conflict resolution ensures provisioning can proceed without manual intervention, even when your standard naming conventions result in conflicts.

Overview

When connecting to integrated systems (see ), 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 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 API.

Overview

You can use Lookup transformers to convert identity attributes from a source system into appropriate values for target systems based on CSV reference tables. This is particularly useful when mapping values between systems that use different naming conventions, codes, or formats for the same conceptual data.

For example, you might need to transform a "Location" attribute from Workday (which might be stored as location codes like "MN001") into corresponding values for country, country code, or city names in a target system.

Use Table Lookup Transformers when:

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.

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 for detailed information.

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.

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.

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:

For activating a re-hired employee:

Empty Values

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

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:

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:

Table of transformation functions

Refer to the page for a comprehensive list of all supported functions and parameters. Contact Veza if you require additional transformations for your use case. 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

Using the ASCII Transformer

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

1. Removes all non-printable ASCII 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, 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 for LDAP integration or to standardize 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 . Date Components:

• 2006 = 4-digit year

• 06 = 2-digit year

• 01 = 2-digit month (01-12)

• 1 = 1-digit month (1-12)

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)

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”

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”

Common Layout Examples

Usage Examples

Basic Date Formatting:

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

Converting Between Specific Formats:

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.

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

Human-Readable Format:

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

Includes time zone information in the output.

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

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 formats 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:

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:

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 ", the result is “johndoe@examplecom”

• Phone number formatting: {phone_number | REMOVE_CHARS, "()- "}

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”

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:

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}

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.

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:

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

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

Example:

Destination Attribute

Formatter

Formatter

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.

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.

Supported Multi-Value Attributes:

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

• organizationalStatus, departmentNumber, employeeType

• servicePrincipalName, proxyAddresses

• member

Syntax:

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

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:

And you apply the transformer:

The resulting value is:

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