Fallback Formatters
Configure fallback formatters for uniquely identifying attributes during identity synchronization
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 Sync Identities Action 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:
Edit or create a Lifecycle Management policy
Edit the workflow containing the Sync Identities action
In the Sync Identities action configuration, click Add Fallback
Configure the Transformer to use as a fallback pattern for the unique attribute that might experience conflicts
Close the action sidebar and save your changes to the policy.
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:
{first_initial}{last_name}{RANDOM_ALPHANUMERIC_GENERATOR(4)}
This could generate usernames like jsmith8f3d
instead of sequential jsmith1
, jsmith2
, etc.
Using UUID for Guaranteed Uniqueness:
{first_initial}{last_name}-{UUID_GENERATOR() | SUB_STRING,0,8}
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:
Select the attribute that requires uniqueness (e.g., username, email)
Configure the primary pattern (e.g.,
{first_initial}{last_name}
)Add a fallback using the
NEXT_NUMBER
transformer to generate sequential alternatives:
{first_initial}{last_name}{NEXT_NUMBER(1, 10)}
This will generate up to 10 alternatives: jsmith1, jsmith2, ... jsmith10
Common Fallback Patterns
Here are some commonly used fallback patterns:
{first_initial}{last_name}
{first_initial}{last_name}{NEXT_NUMBER(1, 10)}
jsmith, jsmith1, jsmith2, etc.
{first_name}.{last_name}
{first_name}.{last_name}{NEXT_NUMBER(1, 10)}
john.smith, john.smith1, john.smith2
{first_name}{last_initial}
{first_name}{last_initial}{NEXT_NUMBER(1, 10)}
johns, johns1, johns2
How Fallback Resolution Works
When Lifecycle Management attempts to provision a new identity with a unique attribute value that already exists:
The system first tries the primary format (e.g.,
jsmith
)If a conflict is detected, it automatically tries the first alternative using the
NEXT_NUMBER
transformer (e.g.,jsmith1
)If that value also exists, it tries the next alternative (e.g.,
jsmith2
)This process continues until either:
A unique value is found
All alternatives from the
NEXT_NUMBER
range are exhausted (in which case an error would be reported)
This automated conflict resolution ensures provisioning can proceed without manual intervention, even when your standard naming conventions result in conflicts.
Last updated
Was this helpful?