Trigger Conditions Reference

Complete reference for SCIM filter syntax used in Lifecycle Management workflow trigger conditions

This page provides a comprehensive reference for the SCIM filter syntax used in Lifecycle Management workflow trigger conditions. Trigger conditions determine when a workflow action should execute based on identity attributes.

SCIM Filter Syntax Overview

SCIM (System for Cross-domain Identity Management) filter syntax provides a standardized way to express conditions. The basic structure is:

<attribute> <operator> <value>

For example:

department eq "Engineering"

This condition evaluates to true when the identity's department attribute equals "Engineering".

Comparison Operators

String Operators

Operator	Name	Description	Example
eq	Equal	Exact match (case-sensitive)	department eq "Sales"
ne	Not Equal	Does not match	status ne "Terminated"
co	Contains	Substring match	email co "@company.com"
sw	Starts With	Prefix match	employee_id sw "EMP"
ew	Ends With	Suffix match	email ew "@company.com"
pr	Present	Attribute exists and is not null	manager_id pr

Numeric Operators

Operator	Name	Description	Example
eq	Equal	Exact numeric match	department_code eq 100
ne	Not Equal	Does not equal	level ne 0
lt	Less Than	Strictly less than	access_level lt 5
le	Less Than or Equal	Less than or equal to	risk_score le 50
gt	Greater Than	Strictly greater than	tenure_months gt 12
ge	Greater Than or Equal	Greater than or equal to	salary_grade ge 3
pr	Present	Attribute exists and is not null	access_level pr

Boolean Operators

Operator	Name	Description	Example
eq	Equal	Boolean match	is_active eq true
ne	Not Equal	Boolean inverse	is_contractor ne true
pr	Present	Attribute exists and is not null	is_contractor pr

Timestamp Operators

Timestamp comparisons use ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ).

Operator	Name	Description	Example
eq	Equal	Exact timestamp match	hire_date eq "2024-01-15T00:00:00Z"
lt	Before	Earlier than	termination_date lt "2024-06-01T00:00:00Z"
le	At or Before	At or earlier than	start_date le "2024-12-31T23:59:59Z"
gt	After	Later than	hire_date gt "2023-01-01T00:00:00Z"
ge	At or After	At or later than	last_login ge "2024-01-01T00:00:00Z"
pr	Present	Attribute exists and is not null	termination_date pr

String List Operators

For attributes that contain multiple values (arrays), the following operators are supported:

Operator	Name	Description	Example
co	Contains	List contains a specific value	employee_types co "Full Time"
eq	Equal	List exactly matches value(s)	roles eq "Admin"
ne	Not Equal	List does not match value(s)	tags ne "deprecated"
pr	Present	Attribute exists and is not empty	groups pr

The co operator is most commonly used for checking membership in a list. Use eq for exact list matching and pr to verify the attribute has any values.

Logical Operators

Combine multiple conditions using logical operators.

Operator	Description	Example
and	Both conditions must be true	is_active eq true and department eq "IT"
or	Either condition must be true	department eq "IT" or department eq "Engineering"
not	Negates a condition	not(status eq "Terminated")

The not() operator uses parenthetical notation. For simple negation of a single value, prefer using ne (not equals) which has broader support across all condition contexts.

Limitation: The not() operator may not be fully supported in all LCM trigger condition contexts. If you encounter unexpected behavior with not(), rewrite the condition using ne or restructure the logic. For example, instead of not(status eq "Active"), use status ne "Active".

Precedence

• not has the highest precedence

• and has higher precedence than or

• Use parentheses () to control evaluation order

Example combining operators:

# Full-time employees in Engineering or IT departments
employee_types co "Full Time" and (department eq "Engineering" or department eq "IT")

Common Trigger Condition Patterns

Joiner Scenarios

# New full-time employees in specific departments
employee_types co "Full Time" and (department eq "Engineering" or department eq "Sales")

# New hires with specific job levels
is_active eq true and job_level ge 3 and hire_date gt "2024-01-01T00:00:00Z"

# Contractors starting in a specific region
is_contractor eq true and location sw "US-"

Mover Scenarios

Mover detection uses the sys_attr__is_mover system attribute, which indicates whether any monitored property has changed. Configure which properties to monitor in the policy's Mover Properties settings.

# Detect any change in monitored properties for active employees
sys_attr__is_mover eq true and is_active eq true

# Department-specific mover handling (user moved AND is now in Engineering)
sys_attr__is_mover eq true and department eq "Engineering"

# Mover detection combined with employment type
sys_attr__is_mover eq true and is_active eq true and employee_types co "Full Time"

The sys_attr__is_mover attribute is a boolean flag set when any property in the configured mover properties list changes. To trigger workflows only when specific attributes change, use the Run only if specific properties change workflow option.

Leaver Scenarios

# Terminated employees
employment_status eq "Terminated"

# Inactive contractors
is_active eq false and is_contractor eq true

# Users with imminent termination date
termination_date le "2024-12-31T23:59:59Z" and termination_date gt "2024-01-01T00:00:00Z"

Attribute-Based Access Control

# High-privilege access for senior engineers
department eq "Engineering" and job_level ge 5 and is_active eq true

# Region-specific access
location sw "EMEA-" and employee_types co "Full Time"

# Cost center based provisioning
cost_center eq "CC-1000" and is_active eq true

System Attributes in Conditions

Lifecycle Management provides computed system attributes (prefixed with sys_attr__) for use in trigger conditions. The most commonly used is sys_attr__is_mover for detecting changes in monitored properties.

See System Attributes for the complete reference.

Dynamic Value Comparisons with Embedded Transformers

For time-sensitive workflows, you can embed transformer functions directly in condition values. This enables comparisons against dynamically-computed dates and times rather than static values.

Syntax

Embedded transformers use the {| FUNCTION | ...} syntax. The pipe (|) immediately after the opening brace indicates there is no source attribute—the expression starts directly with a function:

{| NOW | UTC_TO_TIME_ZONE, "-05:00" | DATE_FORMAT, "DateOnly"}

This differs from attribute transformers where you reference an attribute first:

• Attribute transformer: {hire_date | DATE_FORMAT, "DateOnly"} (starts with attribute)

• Embedded in condition: {| NOW | DATE_FORMAT, "DateOnly"} (starts with function)

Common Functions for Dynamic Conditions

Function	Purpose	Example
NOW	Current UTC timestamp	`{
UTC_TO_TIME_ZONE	Convert to specific timezone	`{
DATE_ADJUST_DAY	Add/subtract days	`{
DATE_FORMAT	Format for comparison	`{

See Transformer Reference for all available functions.

Example: 2-Day Leaver Window

Trigger a leaver workflow when an employee's last day of work falls within a 2-day window around today (Eastern Standard Time):

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 down the embedded transformer:

Step	Function	Input	Output
1	NOW	(none)	Current UTC timestamp
2	UTC_TO_TIME_ZONE, "-05:00"	UTC timestamp	Eastern time timestamp
3	DATE_ADJUST_DAY, 0	EST timestamp	Today (or -2 for 2 days ago)
4	DATE_FORMAT, "DateOnly"	Adjusted timestamp	Date string for comparison

Result: The workflow triggers when:

• The employee is active (is_active eq true)

• Their last day is today or earlier (le today)

• Their last day is after 2 days ago (gt 2 days ago)

This creates a 2-day processing window for departing employees.

Example: Pre-Hire Provisioning

Trigger a joiner workflow 7 days before an employee's start date:

is_active eq false
and hire_date le "{| NOW | DATE_ADJUST_DAY, 7 | DATE_FORMAT, \"DateOnly\"}"
and hire_date gt "{| NOW | DATE_FORMAT, \"DateOnly\"}"

This triggers for employees whose hire date is within the next 7 days, enabling pre-provisioning of accounts before their start date.

Example: Post-Termination Cleanup

Trigger a cleanup workflow for employees terminated more than 30 days ago:

employment_status eq "Terminated"
and termination_date lt "{| NOW | DATE_ADJUST_DAY, -30 | DATE_FORMAT, \"DateOnly\"}"

Escaping quotes: When embedding transformers in conditions, you must escape inner quotes with backslashes. For example: \"-05:00\" and \"DateOnly\".

Timezone consideration: Use UTC_TO_TIME_ZONE to ensure date comparisons align with your organization's business timezone. Without timezone conversion, comparisons use UTC which may cause workflows to trigger at unexpected times.

Related Documentation

For a conceptual overview of how conditions and transformers work together, see Understanding Conditions and Transformers.

Best Practices

Use Specific Conditions

# Good: Specific and targeted
department eq "Engineering" and job_level ge 3 and is_active eq true

# Avoid: Too broad, may affect unintended users
department eq "Engineering"

Test with Dry Run

Before enabling a policy, use the Dry Run feature to preview which identities match your trigger conditions. This helps catch overly broad or restrictive conditions before they affect real accounts.

Combine Conditions Thoughtfully

# Use parentheses for clarity when mixing and/or
(department eq "IT" or department eq "Engineering") and is_active eq true

# Without parentheses, this evaluates differently due to precedence:
# department eq "IT" or (department eq "Engineering" and is_active eq true)
department eq "IT" or department eq "Engineering" and is_active eq true

Handle Edge Cases

Consider what happens when attributes are null or empty:

# Explicit check for non-empty department
department ne "" and department eq "Engineering"

# Check for active status before other conditions
is_active eq true and department eq "Engineering"

Troubleshooting

Condition Not Matching Expected Users

1. Check attribute names: Ensure the attribute name exactly matches the source attribute (case-sensitive)

2. Verify data types: String values need quotes, booleans don't

3. Review operator choice: co for contains vs. eq for exact match

4. Use Dry Run: Test the condition against specific identities

Condition Matching Too Many Users

1. Add specificity: Combine multiple conditions with and

2. Check for broad patterns: co "" matches all non-null values

3. Verify logical grouping: Ensure and/or precedence is correct

Timestamp Issues

1. Use ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ

2. Include timezone: Always use Z suffix for UTC

3. Check attribute type: Ensure the source attribute is a timestamp, not a string

Related Topics

• Understanding Conditions and Transformers - Conceptual overview of conditions vs. transformers

• Policies - Create and configure Lifecycle Management policies

• Conditions and Actions - Configure workflow actions and their triggers

• Attribute Transformers - Transform attribute values using formatter syntax

• Transformer Reference - Complete list of transformation functions

• System Attributes - Available system attributes for conditions

• Dynamic Access Profiles - Formatter-based profile assignment

• Attribute Mapping - Map source attributes to target attributes