# Access Profiles

Access Profiles govern how application entitlements are assigned to employees across your organization. These profiles define how birthright access should be granted based on segmentation criteria, such as business role, job function, seniority level, location, or group membership. Access Profiles are used by the **Manage Relationship** action to assign users to specific groups, roles, permission sets, or other access-granting entities when specific conditions are met.

Profiles can be configured hierarchically to create a fine-grained model for assigning access to different employee groups. Administrators can position child profiles beneath a parent profile, with each child profile inheriting the parent profile's entitlements.

For instance, a parent profile might be "Sales" (defining all the application entitlements that an individual belonging to the Sales organization should be granted), with child Profiles for "Account Executive," "Sales Engineering," "Sales Operations," and "Inside Sales." Each child Profile will have additional application entitlements specific to those roles. With these profiles configured, a workflow in policy for sales engineers can use just the "Sales Engineering" Profile, which includes the access defined by the "Sales" profile.

#### Example Profiles

| Profile Name            | Target           | Relationship                                             |
| ----------------------- | ---------------- | -------------------------------------------------------- |
| Executive Employees     | Active Directory | Executive Employee - Manager US (Active Directory Group) |
| US Engineering Managers | Active Directory | Engineering - Manager US (Active Directory Group)        |
| Azure Helpdesk Role     | Azure            | Helpdesk Administrator (Azure AD Role)                   |
| Google Asia Employees   | Google Cloud     | Google Asia Employees (Google Group)                     |

Since workflows in Lifecycle Management policies can apply these Profiles at all stages in a user's lifecycle, defining Profiles enables Veza to serve as a source of truth for birthright entitlements for all employees. Access Profiles also define what access-granting relationships to *remove* from users during de-provisioning workflows.

The access granted by a Profile can be defined by both:

* Explicitly-defined, application-specific entitlements, such as roles, groups, permission sets, etc., within the Profile. A single Access Profile can support granting one or more entitlements across one or more applications simultaneously.
* Any entitlements inherited from a parent Profile.

The example below shows Business Roles for teams, managers, and all employees, along with Profiles for different applications. When configuring workflow actions, administrators can choose from one or more Business Profiles to assign the entitlements granted by the child Profiles.

![Inherited Profiles and Business Roles](/files/ZasCGkcTdPSd2matGIWa)

### Access Profile Types

Veza offers two types of built-in Access Profile types for defining birthright entitlements by user segments:

#### Profiles

Profiles are a type of Access Profile used to define access-granting relationships (such as user assignments to groups or roles) within the applications you will provision to users. Profiles are intended to represent a specific set of entitlements across one or more applications that should be granted based on a user's segmentation criteria.

Profiles should be configured in coordination with the application owner, who will best understand the exact permissions and privileges granted by various groups, roles, and other entitlements in each specific application.

#### Business Roles

Business roles are a type of Access Profile used to model your organization's structure, based on a hierarchy of job functions, locations, and titles. Ideally, by itself, a Business Role should not describe specific entitlements but can inherit relationships from other Profiles. These will usually be named according to logical segments that should be assigned to different applications with different levels of access, such as "Sales," "QA Contractors," or "Engineering Managers."

#### Best Practices for Access Profile Types

Business Roles can inherit Profiles to enable a hierarchical approach to birthright access management. You should draft and review Access Profiles to create a map of user entitlements for each application (such as "GitHub Developers" or "Salesforce Administrators").

Create Business Roles that align with your organizational structure, especially considering location, business unit, and functional organization. Then, configure these Business Roles to inherit Profiles that describe the birthright entitlements granted to different user populations.

### Configuring Access Profiles

To create and manage Access Profiles, go to **Lifecycle Management** > **Access Profiles**.

1. Click **Create Access Profile**.
2. Under **Access Profile Details**, choose the **Profile Type** to create:
   1. **Business Role**: Business roles are intended to represent logical units within your organizational structure, and can inherit entitlements defined in other Access Profiles. Use Business Roles to establish segmentation criteria based on location, role, business unit, or functional organization.
   2. **Profile**: Profiles define entitlements that can be assigned to users in target applications, such as groups, roles, or permission sets assigned to users as birthright entitlements. Profiles cannot be inherited from other Access Profiles, but can be inherited by Business Roles. Use this profile type to define the birthright entitlements within one or more applications (such as group memberships or role assignments).
3. **Profile Name and Description**: You should follow a standard naming convention for all profiles to help identify them, describing the employee segment or applications the Access Profile applies to.
4. **Profile Labels**: Labels are available for quickly finding access profiles when configuring actions in a policy. Apply and create labels as needed to organize your Access Profiles by employee segment and the applications they apply to.
5. **Assigned Relationships**:
   1. Click **Add Relationship**
   2. Choose the type of relationship to add:
      * **Access Profile**: Use the **Relationship** menu to pick one or more Access Profiles to grant those business roles or entitlements. This option is not available for Access Profiles of type "Profile".
      * **Relationship**: Choose the target data source and specific entities the Profile will govern access to (such as Google Cloud Platform > Google Group). This option is not available for Access Profiles with the "Business Role" type.
6. Click **Assign** to save the changes.

After saving an Access Profile, you can view its details, edit it, or pause and resume it on the **Lifecycle Management** > **Access Profiles** page.

When configuring a policy to include the Manage Relationships action, you can select any active profile for the target data source. You can also use **Dynamic Access Profiles** to resolve Access Profile names at runtime based on user attributes. See [Dynamic Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-access-profiles.md) for details.

### Access Profile Ownership

Access Profiles can have designated owners who are responsible for managing and maintaining the profile. Owners have elevated permissions to configure the profile, manage its lifecycle, and create additional profiles.

#### Who Can Be Owners

Both **Veza Users** and **Veza Groups** can be assigned as Access Profile owners:

* **Individual Users**: Any Veza platform user with the appropriate permissions
* **Veza Groups**: Both Customer Managed groups (created in Veza) and SCIM Managed groups (provisioned from identity providers). See [Veza Groups](/4yItIzMvkpAvMVFAamTf/administration/administration/users/groups.md) for details on group types and management

#### Owner Eligibility Requirements

To be eligible as an Access Profile owner, a user or group must have the **Creator** permission set for the relevant Access Profile Type. This is a two-step configuration process:

1. **Grant Profile Type Permissions**:
   * Navigate to **Lifecycle Management** > **Settings**
   * Select the **Profile Types** tab
   * Locate the profile type in the table
   * Click the **Actions** button (⋮) for that profile type
   * Select **Manage Permissions** from the dropdown menu
   * In the **Manage Permissions** dialog, select USER or GROUP from the **Type** dropdown
   * Choose the specific user or group to grant Creator permissions
2. **Assign as Owner**: Once a user or group has Creator permissions for the profile type, they can be designated as owners for individual Access Profiles of that type

{% hint style="info" %}
**Group Ownership Behavior**: When a group is assigned as an owner, all its members inherit the ownership capabilities. Individual group members will also appear as available owners in the interface.
{% endhint %}

#### Owner Permissions

When a user or group is designated as an Access Profile owner, they automatically receive three distinct permissions:

1. **Owner permission** on the specific Access Profile
   * **Read**: View the profile's configuration, entitlements, and metadata
   * **Update**: Modify the profile's settings, labels, descriptions, and assigned relationships
   * **Create**: Perform create operations within the profile context
   * **Delete**: Remove the Access Profile
   * Enables full control over the profile's configuration and lifecycle (pause/resume)
2. **Creator permission** globally for all Access Profiles
   * Grants the ability to create new Access Profiles of **any type** (subject to other constraints)
   * Scoped to the entire `access_profiles` table, not limited to specific Profile Types
   * This is a **privilege escalation**: first-time owner assignment grants global creation capability
3. **Viewer permission** on the Access Profile Type
   * **Read**: View details about the profile type configuration and requirements
   * Scoped to the specific Profile Type of the owned profile

These permissions enable owners to not only manage their assigned profiles but also create additional profiles of any type they have access to.

{% hint style="warning" %}
**Privilege Escalation**: Becoming an Access Profile owner grants global Creator permission, allowing the user or group to create Access Profiles of any type (not just the type of the owned profile). Consider this privilege escalation when assigning ownership.
{% endhint %}

#### Managing Owners

Access Profile owners are managed through the Access Profiles interface:

1. Navigate to **Lifecycle Management** > **Access Profiles**.
2. Locate the Access Profile in the list.
3. Click the **Actions** button (⋮) for that profile.
4. Select **Manage Owners** from the dropdown menu.
5. In the **Manage Owners** dialog:
   * Use the **Type** dropdown to select USER or GROUP.
   * Use the **Name** dropdown to select the specific user or group to add as an owner.
   * View and manage existing owners in the list below.
   * Click **Done** to save changes.

{% hint style="warning" %}
**Owner Requirements**: Every Access Profile must have at least one owner. The system will prevent you from removing the last owner from a profile to ensure ongoing management capability.
{% endhint %}

{% hint style="info" %}
**Access Profile Creation Permissions (Early Access)**: By default, only Administrators can create Access Profiles. With Access Controls enabled, you can delegate creation permissions to specific Operators and Groups. See [Manage Access Profile Creation Permissions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/manage-access-profile-permissions.md) for details.
{% endhint %}

### Custom Properties

Custom Attributes are admin-defined metadata fields that can be set on individual Access Profiles. You can use them to tag profiles with organizational context such as cost center, team, compliance classification, or region.

These custom property values are available as parameters during dynamic approval rule evaluation, and support Access Requests approval routing driven by profile metadata. For example, this can enable tagging Access Profiles with a specific cost center and routing them to the appropriate approver group. See [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md) for configuration details.

#### Defining custom attribute schemas

Before custom properties can be set on individual profiles, an administrator must define the allowed attributes:

1. Navigate to **Lifecycle Management** > **Access Profiles**.
2. Click **Settings** in the page header.
3. In the settings sidebar, select **Custom Attribute Definitions**.
4. Add one or more attribute definitions. For each attribute, specify:
   * **Name** — the attribute key used to identify the property on profiles.
   * **Type** — currently String is the only supported type.
   * **Available Values** (optional) — a predefined list of allowed values. When set, the value field becomes a dropdown selector when editing a profile.
5. Save the settings.

Custom attribute schemas are applied across all Access Profiles in the tenant. Definitions cannot be set on individual profile types.

#### Setting custom property values on a profile

Once schemas are defined, a **Custom Properties** section appears when creating or editing any Access Profile:

1. In the Access Profile create or edit form, scroll to the **Custom Properties** section.
2. Click **Add Custom Property**.
3. In the dialog, select the **Property** (attribute name) and enter or select an **Attribute Value**.
   * If the attribute definition includes predefined values, the value field is a dropdown.
   * If no predefined values are set, the field accepts free text.
4. Save the profile.

To edit custom properties for an existing profile, select it from the Profiles list to view details. In the header, locate the **Custom Properties** section and click to add or remove properties.

Custom property values are validated against the current definitions. Property names must match a defined attribute, and values must come from the predefined list when one is configured.

Custom property values are included in the API response when retrieving or listing Access Profiles via the `custom_properties` field (private API).

{% hint style="warning" %}
**Cascade removal**: If a custom attribute definition is removed from Access Profiles Settings, the system automatically removes that property from all profiles that had a value set for it. This cleanup is immediate and permanent. Review which profiles use a property before removing its definition.
{% endhint %}

### See Also

* [Manage Relationships](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md)
* [Dynamic Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-access-profiles.md)
* [Lifecycle Management Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md)
* [Access Profile Types](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/access-profile-types.md)
* [Veza Groups](/4yItIzMvkpAvMVFAamTf/administration/administration/users/groups.md)
* [Manage Access Profile Creation Permissions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/how-to/manage-access-profile-permissions.md) - Delegate Access Profile creation to Operators and Groups (Early Access)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.