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.

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.

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.

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

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

See Also

• 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