Dynamic Access Profiles

Use attribute formatters to dynamically select Access Profiles at runtime based on user attributes

Overview

Dynamic Access Profiles enable context-aware provisioning by enabling the Manage Relationships action to resolve Access Profile names at runtime using user attributes.

Instead of explicitly selecting static Access Profiles when configuring a workflow, you can use attribute formatter expressions that evaluate to Access Profile names dynamically when the workflow executes. This is particularly valuable for organizations with complex access patterns based on attributes like department, location, role, or business unit.

This feature eliminates the need for separate workflow conditions for each profile combination, supporting configurations where a single workflow provisions users to different Access Profiles based on their identity attributes.

Terminology: Dynamic Access Profiles use formatter syntax—the same template syntax used in attribute transformers. A formatter is a template string like {department | LOWER} that constructs a value from identity attributes. See Understanding Conditions and Transformers for more context.

How It Works

Runtime Resolution Process

When a Lifecycle Management workflow runs with dynamic Access Profiles configured:

1. Attribute Evaluation: The system evaluates each dynamic Access Profile formatter expression using the identity's attributes. For example, if the expression is dept-{department | LOWER} and the user's department attribute is Engineering, the system evaluates this to dept-engineering.

2. Name Resolution: The evaluated expression produces an Access Profile name.

   Access Profiles must be named using a predictable, consistent pattern to facilitate resolution. Without consistent naming conventions, dynamic profile resolution will fail to match existing profiles.

3. Profile Lookup: Veza looks up an Access Profile with that exact name

4. Profile Application: If the profile exists in the RUNNING state, its entitlements are applied. Resolved profiles can contain entitlements across multiple target integrations, and dynamically resolved profiles can inherit entitlements from other profiles.

5. Graceful Continuation: If the profile name doesn't resolve or doesn't exist, Veza logs the issue to the Activity Log and continues processing any other Access Profiles. This is the default behavior and ensures missing or non-existent profiles don't cause the entire workflow to fail.

Failure Handling: Dynamic Access Profile resolution failures do not stop workflow execution. When a profile cannot be resolved or doesn't exist, the system logs "Dynamic access profile not found" to the Activity Log and continues processing other profiles. This prevents a single missing profile from blocking all access provisioning.

Key Characteristics

• Name-based Lookup: Dynamic Access Profiles resolve to profile NAMES, not IDs

• Naming Convention Critical: Access Profiles must be named using a predictable, consistent pattern

• Profile Inheritance Support: Dynamically resolved profiles can inherit entitlements from other profiles

• Multi-Integration Support: Resolved profiles can contain entitlements across multiple target integrations

• Graceful Failure: By default, missing or non-existent profiles don't cause the entire workflow to fail

Dynamic and static Access Profiles can be used together in the same action.

Comparison: Static vs. Dynamic Access Profiles

Aspect	Static Access Profiles	Dynamic Access Profiles
Selection Time	Policy configuration time	Workflow execution time
Identifier Type	Access Profile ID	Access Profile name (resolved from expression)
Validation	Profile existence validated when saving policy	Expression syntax validated when saving policy; profile existence checked at runtime
Flexibility	Fixed set of profiles	Adapts based on user attributes
Use Case	Universal access for all users in a workflow	Conditional access based on attributes
Scalability	Requires separate conditions for variations	Single workflow handles all variations
Failure Behavior	Policy creation fails if profile doesn't exist	Graceful continuation if profile doesn't exist

Configuration

Prerequisites

Before configuring Dynamic Access Profiles:

1. Create Access Profiles following a consistent naming convention that includes attribute values

2. Identify User Attributes that will drive profile selection (e.g., department, location, role)

3. Plan Naming Pattern that incorporates these attributes predictably

Configuring Dynamic Access Profiles

1. Navigate to Lifecycle Management > Policies

2. Create or edit a policy

3. Add or edit a Manage Relationships action

4. In the Dynamic Access Profiles section:

   • Click Add Profile Name to add a new dynamic profile expression

   • Enter an attribute formatter expression that evaluates to an Access Profile name

   • Use the autocomplete to reference available attributes

   • Add multiple dynamic profile expressions as needed

Formatter Expression Syntax

Dynamic Access Profile expressions use the attribute formatter syntax:

{attribute_path | formatter | formatter_2}

Common Patterns include:

• {department} - Direct attribute value

• {department | LOWER} - Convert attribute value to lowercase

• {OAA.Secondary.Employee.department} - Attribute from a secondary source of identity

• TEAM-{department}-{businessUnitCode} - Multiple attributes combined with static text

• {location | UPPER}-{role | LOWER} - Multiple attributes with different formatters

You can configure multiple dynamic Access Profile expressions in a single action by clicking Add Profile Name for each additional expression. Each expression is evaluated independently.

Conditional Profile Selection with IF/ELSE

You can use IF/ELSE conditional logic within a Dynamic Access Profile expression to select different profile names based on user attributes. This allows a single expression to evaluate to different Access Profile names depending on the identity's properties.

Syntax:

IF <condition>
  <profile_name_if_true>
ELSE
  <profile_name_if_false>

You can use multiple ELSE IF branches to check several conditions in sequence:

IF <condition1>
  <profile_name_1>
ELSE IF <condition2>
  <profile_name_2>
ELSE IF <condition3>
  <profile_name_3>
ELSE
  <default_profile_name>

Multi-Branch Expressions Work in a Single Field

A single IF/ELSE IF/ELSE block with multiple branches is one expression and works perfectly in one Access Profile Name field. The expression evaluates conditions top-to-bottom and returns the first matching profile name.

Example: Department-Based Profile Selection

IF customprop_custom_department eq "Legal"
  Legal Department
ELSE IF customprop_custom_department eq "Mergers and Acquisitions"
  M&A Department
ELSE IF customprop_custom_department eq "Information Technology"
  Information Technology Department
ELSE
  No_Profile_Selected

This single expression handles four different outcomes in one field—no need for multiple fields.

Supported Comparison Operators:

Operator	Meaning	Example
eq	Equals	department eq "Engineering"
ne	Not equals	status ne "Terminated"
co	Contains	groups co "Admins"
sw	Starts with	location sw "US-"
ew	Ends with	email ew "@company.com"
gt	Greater than	employee_count gt 100
ge	Greater than or equal	start_date ge "2024-01-01"
lt	Less than	risk_score lt 50
le	Less than or equal	level le 5

Combine conditions with and, or, or negate with not. Use parentheses to group complex conditions.

When Multiple Fields Are Required

Use separate Access Profile Name fields only when you need to assign multiple independent profiles to the same user. Each field can contain one complete IF/ELSE expression.

This requires two separate fields (assigning profiles based on TWO independent criteria):

Access Profile Name (Field 1)	Access Profile Name (Field 2)
Department-based profile	Location-based profile

This does NOT require multiple fields (one criterion with multiple outcomes):

IF department eq "Sales"
  SalesProfile
ELSE IF department eq "Engineering"
  EngineeringProfile
ELSE
  DefaultProfile

Error: Cannot Stack Separate IF Blocks

Placing two separate IF/ELSE blocks in the same field causes the error "ELSE statement has to be last". This happens because the parser sees a second IF keyword after an ELSE statement.

Incorrect (two separate IF blocks in one field):

IF department eq "Sales"
  SalesProfile
ELSE
  No_Profile_Selected

IF location eq "US"
  USProfile
ELSE
  No_Profile_Selected

Correct approaches:

1. For multiple outcomes from the same criterion, use ELSE IF branches:

   IF department eq "Sales"
     SalesProfile
   ELSE IF department eq "Engineering"
     EngineeringProfile
   ELSE
     No_Profile_Selected

2. For independent criteria, use separate Access Profile Name fields (click Add Profile Name).

Example: Complex Conditions with Logical Operators

IF ((department eq "Finance") or (department eq "DigitalSales") or (department eq "FP&A") or (department eq "Fiscal Operations")) and (job_title eq "Account Manager")
  SalesforceAdmins
ELSE
  No_Profile_Selected

This expression assigns the SalesforceAdmins profile to users who meet the complex department/role criteria, and No_Profile_Selected (a placeholder that resolves to no profile) for everyone else.

Using No_Profile_Selected as a Fallback

When using IF/ELSE logic, the ELSE branch must provide a value. If you don't want to assign a profile when conditions aren't met, use a placeholder name like No_Profile_Selected that doesn't match any actual Access Profile. The system will log that the profile wasn't found and continue processing other profiles gracefully.

Example: Configuring three dynamic profiles for department, location, and role-based access:

Access Profile Name
`dept-{department
`location-{location
`role-{role

In this configuration, the user receives entitlements from up to three Access Profiles based on their attributes. Each expression is added as a separate profile in the UI.

Examples

Example 1: Department-Based Access Profiles

Scenario: Provision users to department-specific Access Profiles based on their department attribute.

Access Profile Setup:

• Create Access Profiles named: access-profile-engineering, access-profile-sales, access-profile-qa

• Each profile contains entitlements appropriate for that department

Dynamic Access Profile Configuration:

{department | LOWER}

With this formatter prefix:

access-profile-{department | LOWER}

Runtime Behavior:

• User with department=Engineering → Access Profile access-profile-engineering

• User with department=Sales → Access Profile access-profile-sales

• User with department=QA → Access Profile access-profile-qa

Example 2: Multi-Attribute Profile Selection

Scenario: Provision users based on both department and business unit for more granular access control.

Access Profile Setup: Create Access Profiles with names combining department and business unit:

• TEAM-Engineering-12345

• TEAM-Engineering-67890

• TEAM-Sales-12345

• TEAM-QA-12345

Dynamic Access Profile Configuration:

TEAM-{department}-{businessUnitCode}

Runtime Behavior:

• User with department=Engineering and businessUnitCode=12345 → Access Profile TEAM-Engineering-12345

• User with department=Sales and businessUnitCode=12345 → Access Profile TEAM-Sales-12345

• User with department=QA and businessUnitCode=12345 → Access Profile TEAM-QA-12345

Example 3: Location and Role Combination

Scenario: Provision users based on geographic location and job role.

Access Profile Setup:

• US-manager

• US-engineer

• EMEA-manager

• EMEA-engineer

Dynamic Access Profile Configuration:

{location | UPPER}-{role | LOWER}

Runtime Behavior:

• User with location=us and role=Manager → Access Profile US-manager

• User with location=emea and role=Engineer → Access Profile EMEA-engineer

Example 4: Combining Static and Dynamic Profiles

Scenario: All employees get a base access profile, plus department-specific access.

Manage Relationships Action Configuration:

• Access Profiles (static): all-employees-base-access

• Dynamic Access Profiles: dept-{department | LOWER}

Runtime Behavior: Every user receives:

1. Entitlements from all-employees-base-access (static)

2. Entitlements from their department-specific profile (dynamic)

Example 5: Secondary Node Attributes

Scenario: Use attributes from a secondary identity source.

Setup:

• Primary identity: Okta User

• Secondary identity: HRIS Employee record with department attribute

Dynamic Access Profile Configuration:

access-profile-{OAA.Secondary.Employee.department | LOWER}

Runtime Behavior: The system evaluates the department attribute from the secondary HRIS Employee node, not the primary Okta User node.

Example 6: Multi-Branch Department Selection (Single Field)

Scenario: Assign different Access Profiles based on which department a user belongs to. Since this is one criterion with multiple possible outcomes, use a single expression with ELSE IF branches.

Access Profile Setup:

• Legal Department - For Legal department users

• M&A Department - For Mergers and Acquisitions users

• Information Technology Department - For IT users

• (No actual profile named No_Profile_Selected exists)

Dynamic Access Profile Configuration:

This uses a single Access Profile Name field with multiple ELSE IF branches:

IF customprop_custom_department eq "Legal"
  Legal Department
ELSE IF customprop_custom_department eq "Mergers and Acquisitions"
  M&A Department
ELSE IF customprop_custom_department eq "Information Technology"
  Information Technology Department
ELSE
  No_Profile_Selected

Runtime Behavior:

• User in Legal department → Receives Legal Department profile

• User in M&A department → Receives M&A Department profile

• User in IT department → Receives Information Technology Department profile

• User in any other department → No profile assigned (resolves to non-existent No_Profile_Selected)

This pattern is ideal when you have many possible values for a single attribute. You can add as many ELSE IF branches as needed—all within one field.

Example 7: Independent Criteria (Multiple Fields Required)

Scenario: Assign profiles based on TWO independent criteria—department membership AND user-specific overrides for testing. Since these are unrelated conditions that could both apply simultaneously, use separate fields.

Access Profile Setup:

• SalesforceAdmins - For finance/sales department users with Account Manager role

• Salesforce User - For specific test users

• (No actual profile named No_Profile_Selected exists)

Dynamic Access Profile Configuration:

This requires two separate Access Profile Name fields because you want to potentially assign both profiles to the same user. Click Add Profile Name to add the second field.

Access Profile Name (Field 1) - Department/Role based:

IF ((department eq "Finance") or (department eq "DigitalSales") or (department eq "FP&A") or (department eq "Fiscal Operations")) and (job_title eq "Account Manager")
  SalesforceAdmins
ELSE
  No_Profile_Selected

Access Profile Name (Field 2) - Test user override:

IF first_name eq "user04"
  Salesforce User
ELSE
  No_Profile_Selected

Runtime Behavior:

• User in Finance department with "Account Manager" title → Receives SalesforceAdmins profile

• User with first_name "user04" → Receives Salesforce User profile

• User meeting both conditions → Receives both profiles

• User meeting neither condition → No profiles assigned (both resolve to non-existent No_Profile_Selected)

When to use multiple fields: Use separate fields only when you need to assign multiple profiles independently. If you're selecting ONE profile from multiple options, use ELSE IF branches in a single field instead.

Best Practices

Naming Conventions

Success with Dynamic Access Profiles depends on establishing consistent naming patterns for your Access Profiles:

• Use clear delimiters: Choose hyphens or underscores consistently (e.g., dept-engineering for department-based profiles or TEAM-dept-bu for multi-attribute combinations)

• Add prefixes to organize: Group profiles by category (e.g., dept-{department}, loc-{location}, TEAM-{dept}-{bu})

• Handle case sensitivity: Profile names are case-sensitive. Use transformers like LOWER or UPPER in your expressions to normalize values, and document your chosen convention

• Document your convention: Ensure all teams follow the same naming pattern

Using IF/ELSE Conditionals

• Use ELSE IF for related conditions: When selecting one profile from multiple options based on the same attribute (e.g., department), use a single IF/ELSE IF/ELSE expression with multiple branches—this keeps your configuration simple and readable

• Use multiple fields for independent criteria: Only add separate Access Profile Name fields when you need to evaluate completely independent conditions (e.g., one profile based on department AND another based on location)

• Use fallback placeholders: When a condition shouldn't assign a profile, use a non-existent name like No_Profile_Selected as the ELSE value—the system will gracefully skip it

• Test complex conditions: Use the Test Formatter feature to validate your IF/ELSE logic before deploying to production

Timing and Order

• Create profiles before processing: Always create Access Profiles before running workflows that reference them

• The system performs name lookups at runtime: If a profile doesn't exist, it will be skipped

• Plan for new attribute values: When adding new departments, locations, or roles to your organization, remember to create their corresponding Access Profiles first to avoid provisioning gaps

Validation and Monitoring

Before deploying to production, validate your configuration using dry-run mode to confirm profiles resolve correctly and attribute values match profile names exactly. Monitor your Lifecycle Management logs for "Dynamic access profile not found" messages, which indicate naming mismatches or missing profiles.

Troubleshooting

Issue	Cause	Solution
Profile not found in Activity Log	Name mismatch or profile is PAUSED	Check Activity Log for the exact resolved name; verify profile exists and is in RUNNING state
Formatter fails to resolve	Missing attribute or incorrect path	Verify attribute exists on identity node; check secondary node paths exist
Wrong profile applied	Similar profile names	Use distinctive naming patterns; avoid profile names that are substrings of others
ELSE statement has to be last	Two separate IF blocks in one field	You cannot stack two separate IF/ELSE blocks in one field. Solution: Either combine related conditions using ELSE IF branches in a single expression (see Example 6), or use separate Access Profile Name fields for truly independent criteria (see Example 7).

See Also

• Understanding Conditions and Transformers - Conceptual overview of the different evaluation systems

• Access Profiles - Creating and managing Access Profiles

• Manage Relationships Action - Configuring the Manage Relationships action

• Attribute formatters - Available formatters and syntax

• Lifecycle Management Policies - Policy configuration and workflows