> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md). # Manage the Access Catalog Configure Access Profiles and Access Profile Types as Catalog Items in the Access Catalog. Create Access Profiles and publish them as requestable items in the Access Catalog, from selecting entitlements through configuring how the item appears to end users. For background on Access Profiles and their role in Lifecycle Management, see [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md). *** ## Overview Access Profiles are bundles of entitlements that, when published, are exposed as Catalog Items that users can request through the Access Catalog. They define the specific entitlements, roles, or application access available to beneficiaries of an access request. Access Profile Types, such as Profiles and Business Roles, determine the structure and behavior of Access Profiles as well as their visibility, entitlement inheritance, and default Access Request Policy. ### Birthright versus requestable entitlements Access Profiles serve two distinct purposes depending on how their entitlements are configured: * **Birthright entitlements** are automatically provisioned to users who match Lifecycle Management policy conditions. For example, all new hires in the Engineering department automatically receive access to GitHub and Jira. A requester does not act on a birthright entitlement, but the setting does not hide it: the catalog item for a profile lists every entitlement the profile grants, whichever availability each one carries. * **Requestable entitlements** (Available on Request) must be explicitly requested by a user through the Access Catalog. These entitlements are subject to approval workflows and access duration policies defined in Access Request Policies. A single Access Profile can contain both birthright and requestable entitlements. The distinction is configured at the **entitlement level** (see Step 2 below), not the profile level. The setting governs how each entitlement is granted; whether the profile itself appears in the Access Catalog is determined by the conditions in [Step 4](#step-4-configure-catalog-visibility). ### How Access Requests and Lifecycle Management work together Access Requests and Lifecycle Management share several key components: * **Integrations**: The same integration credentials that connect Veza to target applications (Active Directory, Okta, AWS, and others) are used by both LCM birthright provisioning and Access Requests fulfillment. * **Access Profiles**: A single Access Profile can include both birthright and requestable entitlements: LCM policies handle the birthright grants, while Access Requests handles the on-request grants. * **Provisioning actions**: When an access request is approved, Veza executes the same LCM actions (Sync Identities, Manage Relationships) that are used for birthright provisioning. This means the target application must already be integrated with Lifecycle Management and the LCM policy must include the relevant actions. * **Identity correlation**: The requesting user's LCM identity must be correlated with a user account in the target system before an access request can be fulfilled. This correlation is typically established when the LCM policy's workflow syncs the user to the target system, or through [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) configured on the identity provider. * **Logging**: All provisioning events, whether triggered by LCM policy or Access Request approval, are logged in the same activity log and audit trail. *** ## Configuring Access Profiles for use as a Catalog Item Access Profiles configured in the Admin Console manifest as Catalog Items in the Access Hub's Access Catalog. To successfully publish a profile as a requestable catalog item, you need to configure both the access entitlements and the catalog presentation. ### Step 1: Create or edit an Access Profile 1. In the navigation menu, expand **Access Profiles** and select **Profiles**. 2. Select **Create** to open the **Create Access Profile** modal, or select an existing profile and select **Edit** 3. Configure the basic profile settings: * **Name**: Use clear, descriptive names that requesters recognize (for example, "Salesforce Sales User", "AWS Production Read-Only") * **Description**: Administrative description for console users * **Access Profile Type**: Select the appropriate type, for example Profile or Business Role * **Labels**: Add labels to organize and control catalog visibility (for example, "sales", "engineering", "production") ### Step 2: Add entitlements and configure availability When adding entitlements to the Access Profile, you configure whether each entitlement is granted automatically (Birthright) or must be requested (On Request): 1. In the Access Profile editor, navigate to the **Entitlements** step 2. Select one of the two cards: * **Get Suggested Entitlements**: derive entitlements from a set of identities that already hold the access you want to bundle * **Assign Entitlements Manually**: add a blank entitlement row and open the inline editor, where you select the integration or data source, the entity type, and the specific entities Both cards are disabled unless the selected Access Profile Type permits assigning entitlements. When the Access Profile Type is restricted to a single integration or data source, the suggestion card also remains disabled until you select one. 3. For each entitlement, configure the **Availability** dropdown: * **Available On Birthright**: Entitlement is granted automatically to the identities the Lifecycle Management policy matches, with no request. The setting governs how the entitlement is granted, not whether the profile reaches the catalog; see [Step 4](#step-4-configure-catalog-visibility) for that. * **Available On Request**: Entitlement must be explicitly requested through the Access Catalog {% hint style="info" %} **Birthright versus Requestable**: The Birthright/On Request setting is configured at the **entitlement level**, not the profile level. A single Access Profile can contain both birthright entitlements (auto-granted) and on-request entitlements (must be requested). {% endhint %} The **Availability** dropdown is present only when the Access Requests capability is enabled for your tenant. Without it, every entitlement in the profile is granted on birthright. 4. Configure entitlement details including target applications, permissions, and conditions 5. Save the profile For detailed instructions on entitlement configuration, see [Configuring Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md#configuring-access-profiles). #### Getting suggested entitlements If you select **Get Suggested Entitlements**, Veza assembles the suggestion set from identities that you choose: 1. Select **Select Source of Identities** and choose the integration or data source that holds the identities. 2. Select either **Select Identities individually** or **Select Identities based on properties**, then define the set of identities. 3. Set the percentage filter. Veza suggests only the entitlements held by at least that share of the selected identities. The default is 50%. 4. Select the entitlements you want, then select **Assign Suggested Entitlements** to add them to the profile. {% hint style="info" %} **How suggestions are derived**: Access Profile Intelligence computes suggestions from the Access Graph, not from a language model. Veza returns the entitlements that the selected identities already hold, together with the percentage of those identities holding each one. Because the results describe access that already exists, review them before adding them to a profile: they can include access that is stale or broader than the role requires. {% endhint %} #### Adding entitlements to a profile that already exists The **Entitlements** step applies to a profile that you are creating. To add entitlements to a profile that already exists, use the profile details page: 1. Open the Access Profile and locate the **Entitlements** table. 2. Select **Add Entitlements**. The **Add Entitlements** modal opens and presents the same two cards. 3. Select a card and choose entitlements as described above. 4. Select **Add** to apply the changes, or **Cancel** to discard them. ### Step 3: Assign ownership Access Profile Owners can serve as approvers and have visibility into requests for their profiles. Ownership is not a step in the profile editor. Assign it from the Access Profiles list once the profile exists: 1. In the navigation menu, expand **Access Profiles** and select **Profiles**. 2. Locate the profile, select the actions menu at the end of its row, and select **Manage Owners**. The **Manage Owners** modal opens. 3. Under the **Add Owner** heading, set **Type** to `USER` or `GROUP`. The dropdown displays these raw values. Owners are Veza users and groups, not accounts in the target application. 4. Select the owner in the **Name** field, then select **Add**. The owner joins the list in the lower half of the modal, where you can remove entries before saving. 5. Repeat for each additional owner, then select **Done**. No change is saved until you select **Done**. The Access Profile details page also presents an **Owners** row with a **Manage** button that opens the same modal. That row appears only after the profile has at least one owner, so assign the first owner from the Access Profiles list. {% hint style="info" %} **General guidelines**: Assign owners who understand the access being granted and can make informed approval decisions. Owners are often application admins, team leads, or security personnel responsible for the target systems. {% endhint %} *** ### Step 4: Configure catalog visibility For a profile to appear in the Access Catalog, it must meet all of the following conditions: 1. The profile is in **Enabled** state. **Enabled** is the console label for the `RUNNING` state; every other profile state is shown as **Disabled**. 2. The profile is permitted by the tenant-wide setting **Access Profiles available in Catalog and while requesting access**, which either allows all Access Profiles, limits the catalog to selected Access Profile labels, limits it to selected Access Profile Types, or allows none. 3. Every data source the profile draws entitlements from is available to the requester. Veza resolves this per requester, from the data sources targeted by the requester's Lifecycle Management policy, the entities already synced for that identity, and the providers where the identity holds a local account. A profile that references a data source outside that set is omitted from that requester's catalog, even when the profile is enabled and permitted by the tenant-wide setting. Configure the tenant-wide setting under **Lifecycle Management** > **Settings** > **Access Request Settings**, in the **Access Profiles Settings** section. Use **labels** as the primary targeting mechanism: assign labels to profiles that correspond to organizational cohorts, then configure the global settings to filter by those labels. A Lifecycle Management policy provides a second route past condition 2. When a **Manage Relationships** action assigns Access Profiles on request rather than on birthright, those profiles become requestable for every identity the workflow processes, and they appear in the catalog for those identities even when the tenant-wide setting excludes them. Conditions 1 and 3 still apply. For a complete explanation of how visibility conditions interact (including the decision flow, profile state requirements, and label-based filtering), see [Catalog Visibility Controls](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#catalog-visibility-controls). For advanced visibility targeting using SCIM filters on Catalog Definitions, see [Managing Catalog Definitions](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md#visibility-rules). **Profile state**: A profile must be in **Enabled** state to appear in the catalog, regardless of other settings. ### Step 5: Verify catalog visibility 1. Navigate to **Access Hub** > **Catalog** as a user in your target cohort 2. Confirm that the configured profiles are visible, correctly labeled, and display the expected description and icon 3. Log in as a user in a **different** cohort to verify that profiles are appropriately hidden 4. Test the request process to confirm profiles are requestable and route to the correct approvers *** ## Customizing catalog display with the Catalog Editor The Catalog Editor allows administrators to customize how Access Profiles appear in the Access Catalog, helping requesters understand what access is included and who should request it. ### Accessing the Catalog Editor To customize an Access Profile's catalog display: 1. In the navigation menu, expand **Access Profiles** and select **Profiles** 2. Find the Access Profile you want to customize in the list 3. Open its row actions menu and select **Catalog Editor** The Catalog Editor is available from the list only. It is deliberately absent from the Access Profile details page, so open it from the row actions menu rather than from the profile itself. The action requires Lifecycle Management update permission. The **"Catalog Editor"** modal opens with the subtitle: "Use the Editor to customize your catalog content to be displayed in the Access Hub page." The editor provides two panels: * **Left panel**: Markdown editor and configuration fields * **Right panel**: Live preview showing how the profile appears in the Access Catalog ### Catalog Editor fields Configure these fields to customize how the Access Profile appears in the Access Catalog: | Field | Description | How to Configure | | --------------------------- | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Add Catalog Icon** | Upload a custom PNG image that appears next to the profile name in catalog card view | Select **"Add Catalog Icon"** button, select a PNG image file. Preview appears immediately. Select the remove icon to delete uploaded image. | | **Markdown Editor** | Rich-text markdown description displayed in the "About this Bundle" section when requesters view catalog item details | Type or paste markdown in the multi-line editor. Placeholder text reads: "Include purpose, target audience, main features, and latest changes." Preview updates in real-time in right panel. | | **Allow to be recommended** | Checkbox that promotes this profile into the **Recommended** section of the Access Catalog | Select the checkbox to enable it. Use it for commonly requested profiles that apply to many users. | {% hint style="info" %} **Icon format**: Use PNG. The file picker filters for PNG files, but the upload is not validated, so a file in another format is accepted and stored. The catalog renders the stored image as a PNG, so PNG is the only format certain to display correctly. No maximum file size is enforced. **Icon size**: The catalog renders the icon at 24 by 24 pixels in every listing. The Catalog Editor renders its own preview at 32 by 32 pixels, so the icon appears larger while you edit than it does in the catalog. Use simple, recognizable images with good contrast. **Live preview**: The preview panel updates as you edit, showing how the profile appears to requesters in the Access Hub catalog. {% endhint %} ### Request form settings The Catalog Editor also includes a **Request form settings** group that changes how the shared request form behaves for this Access Profile. These options affect the requester-facing form only; they do not change what is provisioned. * **Make "Comments" optional**: by default, requesters must complete the Comments field before submitting. Turn this on to let them submit without it. This is a form-level setting only; the backend does not validate the comment either way. * **"Comments" field label**: overrides the label of the Comments field on the request form. Leave it empty to use the default "Comments" label. A common override is "Business Justification". * **Hide the "Explanation" field**: the Explanation field is a dropdown of preset reasons configured in [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md#available-explanations). Turn this on to remove it from the request form for this Access Profile. Unlike the Comments option, this also relaxes server-side validation, so an explanation is no longer required for requests against this profile. A relabeled Comments field applies to the request form. Elsewhere in the console, including the Requests list column and its filter, the field keeps the name Comments. Hiding the Explanation field does not strip the reason from a request. Requests submitted while the field is hidden record the default explanation, "Other". {% hint style="info" %} **Precedence with catalog definitions**: the same three options exist on catalog definitions. When a catalog item has a catalog definition, the definition's values apply and the Access Profile's values act as the fallback. See [Request form options](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md#request-form-options). {% endhint %} ### Writing effective catalog descriptions Use the markdown description to help requesters quickly understand the access bundle: **Purpose**: What this access provides and why it exists * Example: "Provides read-only access to financial reporting dashboards for quarterly reviews." **Target Audience**: Who should request this profile * Example: "Intended for department managers and finance business partners." **Key Features**: Main entitlements or capabilities included * Example: "Includes Tableau dashboards, Snowflake views, and CSV export capabilities." **Prerequisites**: Requirements or dependencies * Example: "Requires Financial Data Handling training (FIN-101)."
Example: Well-formatted Catalog Description ```markdown ## Purpose Quarterly financial reporting access for department leads during budget review periods. ## Who Should Request This - Department managers in quarterly business reviews - Finance business partners supporting planning - Executive assistants preparing leadership materials ## What's Included - **Tableau Dashboards**: View-only Q1-Q4 financial summaries - **Snowflake Data**: Read access to FINANCE.DEPARTMENT_SPENDING views - **Report Exports**: Monthly and quarterly CSV downloads ## Prerequisites Completion of Financial Data Handling training (FIN-101) required. Contact finance-training@company.com to enroll. ```
### Markdown formatting support The catalog description is rendered as GitHub Flavored Markdown. The following syntax is supported: * **Headings**: Use `##` for sections. `#` renders at the largest available size and is rarely suitable in a catalog description. * **Lists**: Use `-` or `*` for bullets, `1.` for numbers * **Emphasis**: Use `**bold**` and `*italic*` for key terms * **Links**: Use `[text](URL)` for external resources. External links open in a new browser tab. * **Images**: Use `![alt text](URL)` * **Code**: Use backticks for inline code, and fenced blocks for multi-line code * **Tables, strikethrough, task lists, and footnotes**: Available through GitHub Flavored Markdown {% hint style="warning" %} The catalog description does not support raw HTML. HTML markup in the description is discarded instead of rendered, so express all formatting in markdown syntax. {% endhint %} ### Using the Recommended flag When **Allow to be recommended** is enabled, the Access Profile is promoted within the Access Catalog: * **Grid view**: The profile appears in a **Recommended** section above the rest of the catalog. The section displays a maximum of four profiles. When more than four are marked, the section presents a **View all** control that opens the full list. * **List view**: The profile appears in a **Recommended** table above the **All** table. * **Manual curation**: Administrators control which profiles are promoted. The flag changes placement only; it does not affect who can see or request the profile. The flag does not create a filter or a sort option. The Access Catalog filters are Categories, Status, Apps, Owner, and Labels, and catalog items are ordered alphabetically by name. {% hint style="info" %} **Inconsistent labeling**: The page that **View all** opens is titled **Popular** rather than **Recommended**. Both names refer to this single flag. {% endhint %} **Use recommended for:** * Common access patterns applicable to many users * Standard role-based access aligning with job functions * Well-established bundles with clear use cases **Avoid recommended for:** * Highly privileged or sensitive access * Specialized access requiring explicit justification * Temporary or project-specific bundles * Profiles under development or testing {% hint style="info" %} **General guidelines**: After customizing catalog display settings, review your catalog entries from the requester's perspective by navigating to **Access Hub** > **Catalog**, so that descriptions are clear, icons are recognizable, and the presentation aligns with your access governance goals. {% endhint %} *** ## Managing Access Profile Types Every Access Profile is assigned an Access Profile Type. The type sets the rules that apply to all profiles that use it: whether a profile holds entitlements of its own, whether it inherits them from another profile, how many entitlements it can hold, which integrations can supply those entitlements, and which Access Request Policy applies to it by default. ### Creating a new profile type 1. In the navigation menu, expand **Access Profiles** and select **Profile Types**. 2. Select **New Profile Type**. A panel opens for the new type. 3. Enter a **Name**, which is the label shown when someone creates an Access Profile of this type. Optionally, add a **Description** and **Instructions**. 4. Under **Relationships**, choose how profiles of this type obtain entitlements. For a type that carries entitlements, at least one of the two settings must be enabled: * **Allow inheritance from other Access Profiles**: a profile of this type inherits its entitlements from another Access Profile. * **Allow direct relationships**: a profile of this type holds entitlements of its own. 5. To govern requests for profiles of this type, select an **Access Request Policy**. Enable **Allow overwrite of Access Request Policy** to let profile creators and owners select a different policy for an individual profile. 6. Select **Create Profile Type**. {% hint style="info" %} The **Profile Types** entry is present in the navigation menu only while **Enable Multiple Profile Types** is active. That setting is on the Access Profile Settings page, which opens when you select **Settings** on the Access Profiles page. While it is inactive, all Access Profiles use a single type and the type options are hidden throughout the console. {% endhint %} A profile type does not carry a visibility or requestability switch of its own. Catalog visibility is determined by the conditions in [Step 4](#step-4-configure-catalog-visibility), one of which can limit the catalog to selected Access Profile Types. For the remaining fields, including On Create Behavior, integration limits, and entitlement options, see [Access Profile Types](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/access-profile-types.md). *** ## General guidelines When working with Access Profiles for Access Requests, the following general guidelines help users find and request the appropriate access and help administrators manage profiles: * **Use clear, descriptive, and consistent naming conventions.** Apply prefixes to create application-specific Access Profile names (for example, "HR Manage Access -" or "Finance Analyst -"), since these names appear in the Access Catalog. * **Keep profiles specific.** Unless a profile is intended as birthright or as a catalog item for all users, design profiles for distinct roles, applications, or functions rather than broad, generic access; granular profiles align access with the principle of least privilege. For example, use "MarketingContentCreator App Bundler" and "SalesforceDataViewer" rather than a single "AllEmployeeAccess" profile. * **Use labels to organize catalog items.** Labels control filtering and visibility in the Access Catalog; examples include "Department: HR", "Application: Salesforce", or "Sensitivity: Confidential". * **Review profiles periodically.** Use Veza Access Reviews to confirm that entitlements stay aligned with current roles, needs, and security policies, and to identify outdated or overly permissive access. Consider quarterly or semi-annual reviews, especially after significant organizational or application changes. *** ## Related documentation * [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md): profile concepts, inheritance, custom properties, and Lifecycle Management integration * [Access Profile Types](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/access-profile-types.md): type configuration, on-create behavior, and inheritance rules * [Access Request Settings](/4yItIzMvkpAvMVFAamTf/features/access-request/settings.md): global catalog visibility, approval permissions, and notification configuration * [Access Request Policies](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-policies.md): approval workflows, JIT access durations, and expiration policies * [Managing Catalog Definitions](/4yItIzMvkpAvMVFAamTf/features/access-request/manage-catalog-definitions.md): advanced catalog types (Application, ServiceNow, REST Payload) with SCIM-based visibility * [Dynamic Approvers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles/dynamic-approvers.md): runtime-resolved approval routing using profile metadata * [Lifecycle Management Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md): workflow configuration for provisioning actions shared with Access Requests --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-request/manage-profiles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.