Understanding Conditions and Transformers

Conceptual guide to the different condition and transformer systems in Lifecycle Management and when to use each

Lifecycle Management automates identity provisioning across your applications. When an employee joins, changes roles, or leaves, workflows answer two questions: Should this person get access? And what should their account look like?

This document explains the building blocks: conditions that control when things happen, and transformers that control what values are set.

Terminology

These terms are used throughout Lifecycle Management documentation.

Term	Definition	Example
Condition	A SCIM filter expression that evaluates to true/false	department eq "Engineering"
Transformer	A complete attribute mapping configuration	Maps email to target, with formatter {first_name}.{last_name}@co.com
Formatter	The template string within a transformer that constructs the value	{first_name}.{last_name}@company.com
Pipeline function	A transformation applied within a formatter	UPPER, LOWER, SUBSTRING

Key relationship: A Transformer CONTAINS a Formatter. The transformer is the complete configuration (which attribute to set, the formatter template, sync options). The formatter is just the template string that defines how to construct the value.

Quick Reference

When You Need To...	Use This System	Syntax Type	Output
Decide IF a workflow runs	Workflow Trigger Condition	SCIM filter	Boolean
Decide IF a subsequent action runs	Condition on Success	SCIM filter	Boolean
Decide WHAT value an attribute should have	Attribute Transformer	Formatter (template)	String
Decide WHICH Access Profile to assign	Dynamic Access Profile	Formatter (template)	String (profile name)

The Four Systems

Workflow Trigger Conditions

Purpose: Determine whether a workflow should execute based on identity attributes.

Syntax: SCIM filter expressions that evaluate to true or false.

Example:

is_active eq true and department eq "Engineering"

When to use: Gate workflow execution based on identity state, department, location, employment type, or other attributes.

See Trigger Conditions Reference for complete syntax documentation.

---

Conditions on Success

Purpose: After a workflow trigger matches, determine whether subsequent actions should run.

Syntax: Same SCIM filter syntax as workflow triggers.

Example:

job_level ge 5 and location sw "US-"

When to use: Create branching logic within a workflow where different actions apply to different identity subsets.

See Conditions and Actions for configuration details.

---

Attribute Transformers

Purpose: Construct attribute values when syncing identities to target systems.

Syntax: Formatter templates with optional pipeline functions.

Examples:

{first_name}.{last_name}@company.com

{first_name | LOWER}.{last_name | LOWER | SUBSTRING, 0, 10}

When to use: Transform source attributes into the format required by target systems (usernames, email addresses, distinguished names, etc.).

Transformers also support IF/ELSE conditional logic to select different values based on identity attributes. See Attribute Sync and Transformers for complete documentation.

---

Dynamic Access Profiles

Purpose: Dynamically determine which Access Profile to assign based on identity attributes.

Syntax: Formatter templates (same as attribute transformers) that resolve to Access Profile names.

Example:

dept-{department | LOWER}

If user's department is "Engineering", this resolves to the Access Profile named dept-engineering.

When to use: Assign Access Profiles based on department, location, role, or other attributes without creating separate workflow conditions for each combination.

Dynamic Access Profiles answer "which profile?" not "should we assign a profile?" They use formatter syntax, not SCIM conditions.

See Dynamic Access Profiles for complete documentation.

---

Combining Conditions and Transformers

Conditions and transformers can work together. Workflow trigger conditions can embed transformer syntax for dynamic value comparisons.

Example: Time-Windowed Leaver Trigger

This condition triggers a leaver workflow when an employee's last day falls within a 2-day window around today:

is_active eq true
and customprop_lastdayofwork le "{| NOW | UTC_TO_TIME_ZONE, \"-05:00\" | DATE_ADJUST_DAY, 0 | DATE_FORMAT, \"DateOnly\"}"
and customprop_lastdayofwork gt "{| NOW | UTC_TO_TIME_ZONE, \"-05:00\" | DATE_ADJUST_DAY, -2 | DATE_FORMAT, \"DateOnly\"}"

Breaking it down:

Component	Layer	Purpose
is_active eq true	SCIM condition	Check if employee is active
customprop_lastdayofwork le ...	SCIM condition	Compare last day to threshold
{| NOW | UTC_TO_TIME_ZONE, "-05:00" | ...}	Embedded transformer	Generate "today in EST" dynamically

The syntax {\| FUNCTION \| ...} (pipe immediately after opening brace) indicates a transformer with no source attribute—it starts directly with a function like NOW.

See Dynamic Value Comparisons for more examples.

---

Summary

Feature	Workflow Conditions	Attribute Transformers
Purpose	Gate execution	Construct values
Output	Boolean (yes/no)	String (the value)
Base syntax	SCIM filter (eq, le, and, or)	Template ({attribute})
Supports IF/ELSE	No (use nested conditions)	Yes
Can embed transformers	Yes, for dynamic values	N/A (is the transformer)
Pipeline functions	Only within embedded values	Yes (| UPPER | LOWER)

---

Related Topics

• Trigger Conditions Reference - Complete SCIM syntax for workflow triggers

• Attribute Sync and Transformers - Formatter syntax and pipeline functions

• Transformer Reference - All available transformation functions

• Dynamic Access Profiles - Formatter-based profile assignment

• System Attributes - Computed attributes like sys_attr__is_mover

• Policies - Creating and configuring Lifecycle Management policies