> 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-hub/configuration.md). # Configuration Configuration guide for Access Hub, including Global Identity Provider setup, Lifecycle Management integration, and catalog functionality. ## Overview Access Hub provides self-service access management through two main experiences: 1. **My Access & My Team**: View existing access and team relationships 2. **Catalog**: Request new access through pre-approved Access Profiles Configuration requires identifying users, establishing manager relationships, and mapping identities across your SSO, HR, and Veza systems. See [Prerequisites](#prerequisites) for requirements by feature. ## Prerequisites Before configuring Access Hub, ensure you have the necessary licenses, permissions, and integrations in place. Missing any of these requirements will prevent Access Hub from functioning correctly. ### For all Access Hub features * **Access Hub license enabled** in your Veza tenant * **Veza administrator account** with appropriate permissions (see [Required Permissions](#required-permissions) below) * [**API token**](/4yItIzMvkpAvMVFAamTf/developers/api/authentication.md) - most configuration steps use Veza's REST API rather than the UI * **Single Sign-On (SSO) configured and functional** - Access Hub relies on SSO to authenticate users and establish their identity. Test SSO authentication before proceeding. ### Required Permissions Access Hub configuration and usage requires different permission levels depending on the operation: **Configuration Permissions (API-based setup):** To configure Global Identity Provider Settings (Step 1), you need **ONE** of the following: * `modify_idp_configuration` permission on the root team * `admin` role * `access_reviews_admin` role **Read-Only Access to Configuration:** To view Global Identity Provider Settings, you need **ONE** of the following roles: * `admin` * `access_reviews_admin` * `operator` * `access_reviewer` * `viewer` * `reassigner` * `watcher` * `access_reviews_monitor` * `nhi_security_admin` Or the `read_configuration` permission on the root team. {% hint style="info" %} **Note:** Most Access Hub configuration is performed via API calls rather than the UI. Ensure your API token has the appropriate permissions before beginning configuration. {% endhint %} ### For My Access and My Team views These views allow users to see their current access and team members who report to them: * **Identity Provider integration** (Okta, Azure AD, etc.) configured in Veza - provides the source of user identity and organizational data * **Manager relationships populated** in your identity system - enables the My Team view and approval workflows * **Global IdP Settings configured** (via API) - tells Veza which identity source to trust as authoritative * **Veza integration enabled** - makes local Veza user accounts visible in the Access Graph for identity mapping ### For Access Hub Catalog The catalog enables self-service access requests. This requires matching user identities from SSO with employee records from your HR system: Catalog functionality requires all items from "My Access and My Team views" above, plus: * **Lifecycle Management license enabled** - catalog functionality is built on LCM * **HR system or identity source integration** configured - provides employee data (name, department, manager, employment status) * **Lifecycle Management identities created** from HR data - establishes employee records that can be mapped to Veza users * **Access Profiles configured and assigned** to users - defines what access can be requested * **Access Requests enabled** in Lifecycle Management settings - activates the request workflow ### Identity Mapping Configuration Points Access Hub requires consistent identity mapping across systems using the same identifier type (employee ID or email) everywhere. | Configuration Point | Purpose | Access Hub Features | Where to Configure | | ----------------------- | ----------------------------------------- | --------------------------- | ------------------------------------------------------------ | | Global IdP Settings | Identify authenticated users and managers | My Access, My Team | `/api/private/workflows/access/global_settings/idp_settings` | | IdP Integration Mapping | Map IdP users to Veza Local Users | My Access, My Team, Catalog | Integration Settings UI | | LCM Identity Settings | Map Veza users to LCM identities | Catalog | Lifecycle Management > Settings | | HR Integration | Source LCM identities from HR system | Catalog | Integration Settings UI | **Example consistent configuration:** If your Global IdP Settings use `employee_id`, then your LCM Identity Settings, IdP Integration, and HR Integration must all also use employee ID as the matching key. ## Architecture and Identity Flow This diagram shows how identity systems connect to enable Access Hub: ```mermaid graph TB %% Source Systems HR[HR System
Workday/BambooHR] IdP[Identity Provider
Okta/Azure AD] %% Core Identity Components LCM[LCM Identity
Employee Records] VezaUser[Veza Local User
SSO Authentication] GlobalIdP[Global IdP Settings
Manager Relationships] %% Configuration Layer IdentityMapping[Identity Mapping
Employee ID/Email] AccessProfiles[Access Profiles
Available for Request] %% Access Hub Features MyAccessTeam[My Access & My Team
Existing Access Views] Catalog[Access Hub Catalog
Self-Service Requests] %% Relationships HR --> LCM IdP --> VezaUser IdP --> GlobalIdP LCM --> IdentityMapping VezaUser --> IdentityMapping IdentityMapping --> Catalog IdentityMapping --> AccessProfiles AccessProfiles --> Catalog GlobalIdP --> MyAccessTeam %% Styling classDef source fill:#e3f2fd,stroke:#1976d2,stroke-width:2px classDef identity fill:#c8e6c9,stroke:#388e3c,stroke-width:2px classDef config fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px classDef feature fill:#ffccbc,stroke:#e64a19,stroke-width:2px class HR,IdP source class LCM,VezaUser,GlobalIdP identity class IdentityMapping,AccessProfiles config class MyAccessTeam,Catalog feature ``` ## Step 1: Configure Global Identity Provider Settings Global IdP Settings specify which identity source Veza queries for user data, manager relationships, and organizational hierarchy. This configuration enables the My Access and My Team views. {% hint style="warning" %} Use your production SSO provider ID, not test or development instances. {% endhint %} ### 1.1 Retrieve your Authorization Provider ID The Global IdP configuration requires an `auth_provider_id` from your SSO configuration. This ID must be retrieved via API. **API Call:** `GET /api/private/auth_providers` ```bash curl -H "Authorization: Bearer YOUR_API_TOKEN" \ https://your-tenant.veza.com/api/private/auth_providers ``` **Response Example:** ```json { "auth_providers": [ { "id": "cf9bab40-4e48-4afc-a310-acfdad416233", "name": "SAML SSO", "auth_provider_type": 2, "enabled": true, "is_configurable": true, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }, { "id": "8a7e3c9f-2b5d-4f1e-9c3a-7d8b4e6f1a2c", "name": "Local Authentication", "auth_provider_type": 1, "enabled": true, "is_configurable": false, "created_at": "2024-01-01T00:00:00Z", "updated_at": "2024-01-01T00:00:00Z" }, { "id": "b3d4e5f6-1a2b-3c4d-5e6f-7a8b9c0d1e2f", "name": "OIDC SSO", "auth_provider_type": 3, "enabled": false, "is_configurable": true, "created_at": "2024-02-10T14:20:00Z", "updated_at": "2024-02-10T14:20:00Z" } ] } ``` **Response Fields:** | Field | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `id` | The unique identifier for this auth provider - use this value as `auth_provider_id` in Global IdP Settings | | `name` | Display name for the authentication provider | | `auth_provider_type` | Integer indicating the provider type (see [Auth Provider Type Values](#11-retrieve-your-authorization-provider-id) below) | | `enabled` | Whether this provider is currently active for user authentication | | `is_configurable` | Whether this provider can be modified through the UI | | `created_at` | ISO 8601 timestamp of when the provider was created | | `updated_at` | ISO 8601 timestamp of the last configuration update | **Selecting the Correct Provider:** For Access Hub configuration, select the provider where: * `enabled: true` - The provider is actively authenticating users * `auth_provider_type: 2` (SAML) or `3` (OIDC/SSO) - Matches your SSO configuration * The `name` matches your SSO provider in **Administration > Sign-in Settings** {% hint style="warning" %} **Important:** Do not use providers with `auth_provider_type: 1` (Local Authentication) or `auth_provider_type: 4` (Support Access) for Access Hub configuration. These are internal authentication methods and should not be configured as Global IdP. {% endhint %} **Auth Provider Type Values:** The `auth_provider_type` field returns an integer representing the authentication provider category: * `1`: `LOCAL_AUTH_PROVIDER` - Local username/password authentication * `2`: `SAML_AUTH_PROVIDER` - SAML-based SSO (includes local\_saml and auth0\_saml implementations) * `3`: `SSO_AUTH_PROVIDER` - Single Sign-On via OpenID Connect (OIDC), Dex, or other SSO implementations * `4`: `SUPPORT_AUTH_PROVIDER` - Support user access * `5`: `SERVICE_ACCOUNT_AUTH_PROVIDER` - Service account authentication * `6`: `TOKEN_JWT_AUTH_PROVIDER` - JWT token-based authentication **Note:** For SAML-based SSO configurations, look for providers with `auth_provider_type: 2` and `enabled: true`. For OIDC-based SSO, look for `auth_provider_type: 3`. For more details on SSO configuration, see [Sign-in Settings](/4yItIzMvkpAvMVFAamTf/administration/administration/sign-in-settings.md). ### 1.2 Gather Identity Provider Information Identify how users and managers are represented in your identity system within Veza. Attribute names vary between providers (Okta, Azure AD, Workday, etc.). Using Veza Query Builder or the Graph, identify the following: * **User Type**: The graph entity type for your users (e.g., OktaUser, AzureADUser, WorkdayWorker) * **Instance ID**: The unique identifier for your IdP instance: * For Okta: Your Okta domain (e.g., dev-5150036.okta.com) * For Azure AD: Your tenant ID (e.g., d5d23474-d857-4e12-bf68-75d638867e93) * For Workday: The datasource ID from the integration * **User Identity Property**: The unique identifier for users * Recommended: `employee_id` (more reliable than email) * Alternative: `email` * Custom: Any unique attribute discovered by Veza * **Manager Identity Property**: The attribute containing manager references (must use the same identifier type as user\_identity\_property) * Examples: `manager_employee_id`, `manager_email`, `managers` ### 1.3 Configure Global IdP Settings **API Call:** `PUT /api/private/workflows/access/global_settings/idp_settings` **Request Body:** ```json { "value": { "enabled": true, "idp": { "auth_provider_id": "cf9bab40-4e48-4afc-a310-acfdad416233", "user_type": "WorkdayWorker", "instance_id": "your-workday-datasource-id", "user_identity_property": "employee_id", "instance_id_property": "datasource_id", "manager_identity_property": "manager_employee_id", "active_user_conditions": { "fn": "EQ", "property": "is_active", "value": true } } } } ``` | Parameter | Description | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `enabled` | Set `true` to enable the provider as a Global IdP | | `auth_provider_id` | Internal UID for the single sign-on provider instance (from Step 1.1) | | `user_type` | Graph entity type to search for users, such as `OktaUser` or `WorkdayWorker` | | `instance_id` | The UID for a provider in the data catalog | | `user_identity_property` | Unique entity property used to identify the IdP user | | `instance_id_property` | The user entity property used to identify the IdP instance (typically `datasource_id`) | | `manager_identity_property` | The user entity property used to identify the manager | | `idp_type` | Optional field that specifies the application type for the identity provider (e.g., "okta", "azure\_ad"). This field is typically set automatically based on the `user_type` and is used for internal classification. | | `active_user_conditions` | Optional filter for identifying active users | ### Example Configurations **Okta Configuration:** ```json { "value": { "enabled": true, "idp": { "auth_provider_id": "your-auth-provider-id", "user_type": "OktaUser", "instance_id": "dev-5150036.okta.com", "user_identity_property": "employee_id", "instance_id_property": "datasource_id", "manager_identity_property": "manager_employee_id" } } } ``` **Azure AD Configuration:** ```json { "value": { "enabled": true, "idp": { "auth_provider_id": "your-auth-provider-id", "user_type": "AzureADUser", "instance_id": "d5d23474-d857-4e12-bf68-75d638867e93", "user_identity_property": "employee_id", "instance_id_property": "datasource_id", "manager_identity_property": "manager_employee_id" } } } ``` **Multiple Active User Conditions:** The `active_user_conditions` field accepts an array for complex filtering: ```json { "active_user_conditions": [ { "fn": "EQ", "property": "is_active", "value": true }, { "fn": "NE", "property": "status", "value": "terminated" } ] } ``` ### Advanced Configuration For organizations with complex identity structures requiring manager lookups across multiple identity providers or secondary sources of identity, see [Alternate Manager Lookup](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings/alternate-manager-lookup.md) for full API documentation and additional configuration options using the `alternate_manager_lookup_settings` parameter. ### Verification To verify your current configuration: ```bash curl -H "Authorization: Bearer YOUR_API_TOKEN" \ https://your-tenant.veza.com/api/private/workflows/access/global_settings/idp_settings ``` ## Step 2: Enable Veza Integration The Veza integration makes your local user accounts (created via SSO) visible as entities in the Access Graph, enabling identity mapping between Veza users and external identity sources. To enable the Veza integration: 1. Navigate to **Integrations > Add Integration** 2. Search for "Veza" and enable the integration 3. **Important:** Check the option to enable for Lifecycle Management and SCIM if using SCIM provisioning - this makes Veza users available as targets for LCM identity mapping 4. After enabling, verify that `Veza Local User` entities appear in Query Builder (schema type: `VezaUser`) For more information, see the [Veza integration guide](/4yItIzMvkpAvMVFAamTf/integrations/integrations/veza.md). ## Step 3: Configure Lifecycle Management for Catalog Functionality The Access Hub catalog requires [Lifecycle Management identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/identities-overview/identities.md) to map Veza users to employee records from your HR system. ### 3.1 Create Lifecycle Management Policy Create a basic Lifecycle Management policy to establish the identity mapping table: 1. Navigate to **Lifecycle Management > Policies** 2. Create a new policy with your identity source (e.g., Workday) 3. Add a basic workflow that creates the identity mapping 4. Use a condition that won't trigger (e.g., `active = "placeholder"`) to create the identity table without executing workflows 5. Publish the policy For detailed policy configuration, see [Lifecycle Management Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md). ### 3.2 Configure Lifecycle Management Identity Settings Enable identity mapping for the catalog functionality: 1. Go to **Lifecycle Management > Settings > Identity Settings** 2. Use the dropdown to choose a **Mapping Type**: * Email * Employee ID This mapping connects Veza local users (created via SSO) to Lifecycle Management identities (created from HR data). ### 3.3 Configure Catalog Application Settings (Early Access) When configuring applications in catalog definitions, administrators can specify advanced settings for how access requests are processed: **Assignee Entity Type Selection** For applications with multiple identity types (e.g., service accounts alongside user accounts), you can specify which entity type should be used as the assignee when processing access requests: 1. Navigate to **Lifecycle Management > Settings > Application Settings** 2. Select the application to configure 3. Under **Assignee Configuration**, use the **Entity Type** dropdown to select the target identity type 4. Click **Save** to apply the configuration ### 3.4 Configure Catalog Definitions Catalog definitions determine how access requests are fulfilled. Each catalog definition has a type that controls what happens when a user submits a request. Four catalog definition types are available: | Type | Description | | --------------------- | -------------------------------------------------------------------------------------------- | | **Application** | Provisions access to entitlements in a connected application via Lifecycle Management | | **ServiceNow** | Creates a ServiceNow ticket when the request is submitted | | **Jira** | Creates a Jira issue when the request is approved, and tracks the issue state back into Veza | | **Send REST Payload** | Calls a configured REST API endpoint directly when the request is submitted | #### Creating a Send REST Payload catalog definition Use this type when you want access requests to trigger a REST API call rather than creating an ITSM ticket. The API call is handled by an existing Send REST Payload action in a provisioning policy. 1. Navigate to **Lifecycle Management > Settings > Catalog Definitions** 2. Click **Add Catalog Definition** 3. Select **Send REST Payload** as the type 4. Configure the catalog definition: * **Grant Action Name**: Select the Send REST Payload action to invoke when a request is approved * **Revoke Action Name**: (Optional) Select the action to invoke when access is revoked * **Form Fields**: Add any fields that requestors must complete when submitting a request. Each field has a name and an optional default value. Field names must contain only letters, numbers, and underscores (for example, `role_name`, `role_id`). Names that include other characters, such as hyphens or spaces, might be saved but will not substitute at execution time; the placeholder is emitted as a literal in the outgoing payload. 5. Click **Save** To use form field values in the REST payload, reference them in the action's JSON payload using `{$form_field.field_name}` syntax, with the placeholder inside a JSON string literal. For example, if you define form fields `role_name` and `role_id`, the action payload can include: ```json {"roleName": "{$form_field.role_name}", "roleId": "{$form_field.role_id}"} ``` When a user submits an access request and fills in these fields, the values are substituted into the payload before the REST call is made. Substituted values are JSON-escaped automatically. For full substitution rules, see [Form field substitution](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md#form-field-substitution-access-requests-only) on the Send REST Request action page. For information about creating Send REST Payload actions, see [Send REST Payload](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/oaa-send-rest-payload.md). #### Creating a Jira catalog definition Use this type when access fulfillment is routed through Jira. For example, when a downstream team must manually provision the request, or when audit and ticketing live in Jira rather than ServiceNow. When a request using a Jira catalog definition is approved, Veza creates a Jira issue from the configured Jira notification. Veza then polls the Jira ticket and advances the access request state as the ticket progresses, ending in **Completed** when the ticket reaches a terminal "done" status. 1. Confirm that the Jira **Veza Action** is already configured for the target Jira project. The Veza Action defines the Jira project, issue type, default fields, and any field mappings used at issue-creation time. Jira Veza Actions are managed under **Integrations > Veza Actions**. 2. Navigate to **Lifecycle Management > Settings > Catalog Definitions**. 3. Click **Add Catalog Definition**. 4. Select **Jira** as the type. 5. Configure the catalog definition: * **Jira Integration**: select the Jira Veza Action to use (the picker is labeled "Select a Jira Veza Action"). Jira Veza Actions are configured under **Integrations > Veza Actions**. * **Headline Template** (optional): becomes the Jira issue summary. Supports `{$form_field.}` for form-field values and `{$access_requestinfo.requestedFor}`, `{$access_requestinfo.requestedBy}`, and `{$access_requestinfo.comments}` for request metadata. * **Message Body Template** (optional): becomes the Jira issue description. Same placeholder grammar as the headline. * **Form Fields** (optional): fields requestors fill when submitting. Reference them in templates via `{$form_field.}`. Field names must contain only letters, numbers, and underscores. For full substitution rules, see [Form field substitution](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md#form-field-substitution-access-requests-only). 6. Click **Save**. **Lifecycle** After approval, the request's state is driven by the Jira ticket lifecycle: | Jira status | Veza access request state | | ----------------------------------------------------------------------------------------------- | ------------------------- | | Status category `to-do` (new) | `WAITING_FOR_APPROVAL` | | Status category `indeterminate` (in progress) | `EXTERNAL_RUNNING` | | Status category `done` (excluding cancelled-equivalents below) | `COMPLETED` | | Status name `Cancelled`, `Canceled`, `Won't Do`, `Wont Do`, or `Will Not Do` (case-insensitive) | `CANCELED` | | Unknown category | no change | The Jira poller runs every 5 minutes by default; the interval can be overridden by the `JIRA_TICKET_POLL_INTERVAL_MINUTES` environment variable on the control plane. * The ticket is created only after the request is approved (when it reaches `PLAN_SELECTED` internally). * Once a request has advanced past `WAITING_FOR_APPROVAL`, the poller will not demote it back, even if the Jira ticket is dragged backward to "To Do." * **Revoking the access request does not close the Jira ticket.** The Jira object persists; close it manually if your operational model requires it. * Each state transition emits an automated note on the access request (e.g., "Jira ticket VEZA-123 transitioned to 'In Progress'"), providing a visible audit trail. Status changes inside Jira that do not move the access request state do not generate notes. {% hint style="warning" %} **Localization caveat.** The cancelled-status set is matched by name, in English only (`Cancelled`, `Canceled`, `Won't Do`, `Wont Do`, `Will Not Do`, case-insensitive). Tenants running localized Jira workflows (for example, a German project where "Won't Do" is labeled *Abgebrochen*) see those tickets fall through to `COMPLETED` via the `done` category instead of `CANCELED`. To route a localized cancellation correctly, alias the localized status name back to one of the English names, or accept that it will land in `COMPLETED`. {% endhint %} For information about configuring Jira notifications, see [Notifications](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications.md). ### 3.5 Enable Access Requests Enable the access request functionality: 1. Go to **Lifecycle Management > Settings > Access Request Settings** 2. Toggle **Enable Requests** For more information about managing access requests, see the [Lifecycle Management documentation](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md). ## Step 4: Configure Integration Identity Mappings [Identity mapping](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) ensures users are consistently identified across integrated systems, connecting your Identity Provider users to Veza local accounts and Lifecycle Management identities. {% hint style="warning" %} **Security:** Misconfigured mappings can allow users to access another person's information. Use unique identifiers (employee\_id recommended over email) and test in a non-production environment first. {% endhint %} ### 4.1 Configure Identity Provider to Veza Local User Mapping Map authenticated users from your IdP (Okta, Azure AD, etc.) to Veza local user accounts: 1. Navigate to **Integrations** and select your Identity Provider (Okta, Azure AD, etc.) 2. Click **Edit** to modify the integration settings 3. Scroll to the **Mapping Configuration** section 4. If no mapping exists, click **Add Mapping Configuration**: * **Use Email By Default**: Enable if your users authenticate with email addresses * **Mapping Mode**: Select **Users** (not Groups) * **Destination Data Source Type**: Select **Veza** from the dropdown 5. Configure **Property Matchers** based on your authentication method: * **For email-based authentication**: * Source Property: **Email** * Destination Property: **Email** * **For employee ID-based authentication**: * Source Property: **Custom Property** (enter your employee ID field name) * Destination Property: **Unique ID** 6. Apply transformations if needed: * **Ignore Domain**: Enable to match users regardless of email domain differences * **Ignore Special Characters**: Enable to handle variations in formatting 7. Click **Save Configuration** ### 4.2 Configure HR System to Lifecycle Management Identity Mapping Your HR system integration must create Lifecycle Management identities from employee records. This mapping is typically established automatically when you create a Lifecycle Management policy using your HR system as the identity source. 1. Navigate to **Integrations** and select your HR system (Workday, BambooHR, etc.) 2. Click **Edit** to modify the integration settings 3. Verify **Custom Properties** includes any required fields: * Employee ID * Manager relationships * Department/organizational data 4. In the **Mapping Configuration** section: * Ensure mapping is configured to create Lifecycle Management identities * Verify the identity property (employee ID or email) matches your Global IdP configuration * Confirm manager relationship fields are properly mapped **Example Configuration:** * Global IdP Settings: `"user_identity_property": "employee_id"` * Lifecycle Management Settings: **Employee ID** mapping type * Okta Integration: Custom Property `employee_id` → Unique ID * Workday Integration: Employee ID field properly extracted and mapped ## Troubleshooting ### Verification Steps Test your configuration by checking the following: 1. **Global IdP Settings**: Users from your IdP appear correctly in Access Hub 2. **SSO Integration**: Users can authenticate and access the platform 3. **Identity Mapping**: Users see their correct access in My Access view 4. **Manager Relationships**: Managers can see their team members in My Team view 5. **Catalog Access**: Users see appropriate Access Profiles in the Catalog ### Common Issues **Issue: Users see duplicate identities or incorrect access** * Verify `auth_provider_id` matches the correct SSO provider from `/api/private/auth_providers` * Check that `user_identity_property` is consistently configured across all systems * Ensure identity mappings use the same identifier type (employee ID or email) **Issue: Managers cannot see their team members** * Verify manager relationships are populated in your identity system * Check that `manager_identity_property` is correctly configured * Review [manager relationship documentation](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/managers-and-resource-owners.md) **Issue: Catalog is empty or Access Profiles don't appear** * Verify Lifecycle Management license is enabled * Check that Access Requests are enabled in Lifecycle Management Settings * Ensure users have corresponding Lifecycle Management identities * Verify Access Profiles are assigned to user identities ## Related Documentation ### Configuration Guides * [Global Identity Provider Settings](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings.md) * [Alternate Manager Lookup](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/global-idp-settings/alternate-manager-lookup.md) * [Managers and Resource Owners](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/managers-and-resource-owners.md) * [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md) ### Lifecycle Management * [Lifecycle Management Overview](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md) * [Lifecycle Management Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/identities-overview/identities.md) * [Access Profiles](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/profiles.md) * [Lifecycle Management Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md) ### Integration Setup * [Okta Integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta.md) * [Azure AD Integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure-ad.md) * [Workday Integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/workday.md) * [Veza Integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/veza.md) ### API Documentation * [API Authentication](/4yItIzMvkpAvMVFAamTf/developers/api/authentication.md) * [Lifecycle Management APIs](/4yItIzMvkpAvMVFAamTf/developers/api/lifecycle-management.md) * [Data Source Management](/4yItIzMvkpAvMVFAamTf/developers/api/management/datasources.md) ### Access Hub Features * [Access Hub Overview](/4yItIzMvkpAvMVFAamTf/features/access-hub.md) * [User Guide](/4yItIzMvkpAvMVFAamTf/features/access-hub/user-guide.md) * [Settings](/4yItIzMvkpAvMVFAamTf/features/access-hub/settings.md) --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.