Attribute synchronization ensures that identity attributes in target systems remain up to date with the corresponding attributes in the source of truth. Veza Lifecycle Management provides configuration at two levels to control how and when attributes are synchronized.

Action Level

At the action level, there are two distinct options to govern provisioning and user update processes:

• Create new users - When enabled, the action will create new user accounts that don't exist in the target system

• Update active users - When enabled, the action can update existing user accounts with attribute changes from the source of truth

Attribute Level

At the attribute level, there are two explicit choices that define how and when attribute values are applied to user accounts:

• Set for new users only - The attribute value is set only when creating new user accounts

• Set for new and existing users - The attribute value is set for new accounts and updated for existing accounts when changes are detected

Both levels must be properly configured for an attribute to be continuously synchronized. For example, to keep an employee's department updated:

1. Enable Update active users on the Sync Identity action

2. Select Set for new and existing users for the department attribute

Recommended Settings

Set for new and existing users (continuously sync attributes that change during employment):

• First Name, Surname

• Department

• Title

• Manager

Set for new users only (preserve stable identifiers):

• Active Directory sAMAccountName

• Email Addresses (for Email Write-Back action)

This configuration ensures that dynamic attributes remain up to date while preserving stable identifiers.

Overview

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

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

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

Attribute Naming Conventions

Veza normalizes all property names for consistency:

The following normalization rules typically apply:

• Source properties are converted to lowercase

• Any spaces and hyphens become underscores

• Special characters removed

Attribute Types and Mappings

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

Standard Attributes

Veza recognizes and standardizes many common attributes across source systems:

Source-Specific Mappings

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

Workday → Veza

Okta → Veza

Active Directory → Veza

Custom Properties

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

• Always prefixed with customprop_

• Automatically discovered during extraction once enabled

• Follow standard normalization rules (lowercase, underscores)

Examples:

• customprop_department_code - Custom department identifier

• customprop_employeeou - Organizational unit

• customprop_region - Geographic region

System Attributes

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

• sys_attr__is_mover - Identity has changed monitored properties

• sys_attr__would_be_value - Preview value in conditional transformers

• sys_attr__would_be_value_len - Preview value length in conditional transformers

See for details.

Using Attributes in Workflows

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

Primary vs Secondary Sources

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

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

Example Usage

Lifecycle Management uses two different expression syntaxes depending on the context:

In Workflow Conditions (SCIM Filter Syntax):

Trigger conditions use SCIM filter syntax to evaluate boolean expressions. See for complete documentation.

In Transformers (Formatter/Pipeline Syntax):

Attribute transformers use curly braces and pipes to produce output values. See for complete documentation.

With Secondary Sources (in Conditions):

See Also

• - Computed attributes for advanced scenarios

• - Modifying and combining attribute values

• - Using attributes in workflow conditions

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

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

See Also

• - Complete SCIM filter syntax for workflow conditions

• - Complete list of transformation functions

• - Attribute transformation concepts and examples

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

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

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

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.

An attribute transformer is the complete configuration for mapping a source attribute to a destination attribute. It consists of:

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.

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.

Key Terminology

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.

Best practices

When to use common transformers

Create common transformers when the same transformation logic appears in two or more places within the policy. Common transformers reduce duplication and ensure consistent formatting across actions.

When to use transformer functions

Create transformer functions when the same transformation applies to multiple properties. Functions let you reuse logic without duplicating configuration.

Formatter syntax

The Formatter field in a transformer specifies how to construct the attribute value. It 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):

Attribute references

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

Examples:

Alias Definitions

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

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

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

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:

Comparison operators

Use these operators in IF conditions to compare attribute values:

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

Examples

In attribute formatters:

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

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:

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:

Transformation function categories

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

Then Apply {#then-apply}

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 Then Apply

• {name | UPPER}

  • If name = Smith, the result is SMITH.

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

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

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

• Action synced attributes

• Unique identifiers

• Common transformers

• Date formatters

Testing Examples

Testing Then Apply

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.

When to Use Inline Testing vs. 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.

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

Using Transformed Attributes as Lookup Keys

You can reference an attribute set by an earlier transformer as the lookup key in a subsequent transformer. This enables multi-stage transformation pipelines where one transformer computes a normalized value, and a later transformer uses that value for table lookups or other operations.

Example: Compute a padded employee ID in one transformer, then use it to look up a cost center in a later transformer:

Transformer 1 — set padded_id:

Transformer 2 — use padded_id as the lookup key:

The $target.padded_id reference resolves to the value set by Transformer 1, and passes it as the key into the LOOKUP function.

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

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

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

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:

• You need to map source attribute values to different values in target systems

• You have standardized reference data that must be consistent across applications

• You need to extract different pieces of information from a single attribute value

Examples

1. Geographic Information:

   • Transform location codes to country, region, city, or timezone information

   • Map office codes to physical addresses or facility types

How It Works

The Table Lookup Transformer references CSV-based mappings between source and destination values. When synchronizing user attributes, Veza:

1. Takes the source attribute value

2. Looks up this value in the specified lookup table

3. Returns the corresponding value from the designated return column

Lookup Table Structure

Lookup tables are CSV files with columns that map values from a source of identity to destination values. Each row represents a mapping entry. The first row must contain the column headers.

For example, a location mapping table might look like:

Creating and Managing Lookup Tables

Creating a Lookup Table

To create a new lookup table:

1. Navigate to the Lookup Tables tab within your policy configuration

2. Click Edit mode to enable policy changes

3. Click Add New to create a new lookup table

Managing Lookup Tables

From the Lookup Tables tab, you can:

• Edit table descriptions or upload a new CSV

• Delete tables that are no longer needed

Updating a lookup table

To update an existing lookup table:

1. Create a new policy draft version.

2. Delete the CSV from the existing lookup table (do not delete the table itself).

3. Upload the updated CSV.

Using Table Lookup Transformers

Basic Syntax

To use a Table Lookup Transformer in a common or action-synced attribute:

1. In Destination Attribute, choose the attribute on the target entity that will be updated

2. In Formatter, choose the source attribute to transform

3. In Then Apply, specify the lookup table name, the column to match against, and the column containing values to return.

The full syntax for using lookup table transformers is:

Where:

• <value> is the source attribute to transform (e.g., {location})

• <table_name> is the name of the lookup table to use

• <column_name>

Examples

Assuming a user has "location": "IL001" and a lookup table named locationTable structured as shown earlier:

Advanced Features

Pipeline Transformations

You can combine lookup transformations with other transformation functions in a pipeline:

This would look up the state_code corresponding to the location value and convert it to lowercase.

Handling Missing Values

When a lookup value is not found in the table, the transformation will fail for that specific attribute.

For full coverage, ensure your lookup table includes entries for all possible source values that may be encountered during provisioning.

To ensure robust provisioning workflows, it's important to include all expected values in your lookup table, validate source data before implementing lookup transformations, and test transformations with representative data sets.

Technical Details

Implementation Notes

• Lookup tables are immutable and automatically deleted when no longer referenced by any policy version

• Multiple policy versions can reference the same lookup table (e.g., an active version and a draft version)

• Lookup tables are defined at the policy level and can be referenced by any transformer within the policy

Best Practices

1. Standardize Naming: To use a lookup-based transformer, you will reference the table by file name. Apply consistent conventions for both the table and columns.

2. Document Mappings: Add descriptions for each lookup table to explain its purpose

3. Validate Data: Ensure lookup tables are complete and accurate before using them in transformers. Consider how lookup tables will be maintained over time, especially for values expected to change.

Troubleshooting

Common Issues

Related Topics

This page includes a comprehensive list of all supported transformer 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, title, sentence, camel, or snake case

• Using a substring from the original value

See for configuration details, or for terminology definitions.

Reading the Examples

Each transformer below includes three types of examples:

1. Basic Usage: Shows the transformer used alone with a simple source attribute

2. In a Pipeline: Demonstrates chaining multiple transformers together

3. Example: Provides practical context from Lifecycle Management scenarios

Copy-paste these examples directly into your attribute transformer configuration, adjusting attribute names to match your source of identity.

DATE_FORMAT

Description: Converts a timestamp to a formatted date string using Go time layout syntax.

Syntax: {attribute | DATE_FORMAT, "layout"} or {attribute | DATE_FORMAT, "output_layout", "input_layout"}

Parameters:

Returns: String — the formatted date/time string

Examples:

Go date format reference

The reference date Mon Jan 2 15:04:05 MST 2006 breaks down as:

Common format patterns

Named format aliases

Instead of Go layout strings, you can use these named aliases (case-insensitive):

For the full list of named aliases (including kitchen, rfc822, rfc1123, stamp, and others), see Go's standard .

Notes:

• Input must be a valid timestamp

• Use with or for timezone handling

• When parsing non-standard input dates, provide both output and input layouts

LOWER

Description: Converts all characters in a string to lowercase.

Syntax: {attribute | LOWER}

Parameters:

Returns: String — the input value with all characters converted to lowercase

Examples:

Notes: Only affects alphabetic characters. Numbers and special characters pass through unchanged.

REPLACE_ALL

Description: Replaces all occurrences of a substring with a replacement string.

Syntax: {attribute | REPLACE_ALL, "search", "replacement"}

Parameters:

Returns: String — the input with all occurrences of search replaced by replacement

Examples:

Notes:

• Case-sensitive matching

• To remove characters, use an empty string as the replacement: REPLACE_ALL, "x", ""

• For removing multiple different characters, consider instead

SUB_STRING

Description: Extracts a portion of a string starting at a specified position.

Syntax: {attribute | SUB_STRING, offset, length}

Parameters:

Returns: String — the extracted substring

Examples:

Notes:

• Index is 0-based (first character is position 0)

• If offset + length exceeds the string length, returns characters up to the end

• For extracting just the first N characters, consider as a simpler alternative

UPPER

Description: Converts all characters in a string to uppercase.

Syntax: {attribute | UPPER}

Parameters:

Returns: String — the input value with all characters converted to uppercase

Examples:

Notes: Only affects alphabetic characters. Numbers and special characters pass through unchanged.