> 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/settings.md).

# Settings

Administrative options for customizing Access Hub behavior, visibility, and user experience.

## Overview

The **Access Hub** > **Settings** page takes two forms. Administrators see the full set of administrative tabs described on this page, which control which features are available to users and what information they can see when they view their authorization data. Users who are not administrators also have a Settings page, but it contains only the individual **Landing Page** preference described in [Account Settings (Landing Page)](#account-settings-landing-page).

To open settings, navigate to **Access Hub** (in the Products section of the navigation sidebar) and click the **Settings** gear icon. Access to the page is governed by the Access Workflow `read_configuration` permission rather than by an administrator role. See [Required Permissions](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md#required-permissions) for the roles that carry it.

> **ℹ️ Note:** Specific options may vary based on your Veza deployment and licensing.

## Product Visibility Settings

The **Product Visibility** tab lets you control which Access Hub features users can access. You can toggle product visibility based on your organization's needs and readiness.

### Core User Features

| Setting       | What it does                                                                                       | Prerequisites                                    |
| ------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------ |
| **My Access** | Users can see their own permissions, roles, and access relationships that Veza has discovered      | Global IdP configuration or LCM Identity mapping |
| **My Team**   | Managers can view their direct reports' access, including outlier flags and pending access reviews | Manager relationships configured in Global IdP   |

### Self-Service Features

| Setting             | What it does                                                                             | Prerequisites                                                                          |
| ------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| **Catalog**         | Users can request access to apps, resources, and profiles through self-service workflows | LCM configuration, Access Profiles, and Access Requests enabled                        |
| **Access Profiles** | Users see Access Profiles they're assigned to or own                                     | Access Requests and Lifecycle Management configuration, and Access Profile assignments |

### Governance Features

| Setting            | What it does                                                         | Prerequisites                              |
| ------------------ | -------------------------------------------------------------------- | ------------------------------------------ |
| **Access Reviews** | People assigned as reviewers can complete access certification tasks | Access Reviews licensing and configuration |

### When to Enable Each Feature

**My Access**: Provides all users with detailed visibility into their own access. Enable for transparency and self-service verification.

**My Team**: For managers who need oversight of their team's access without being full administrators. Requires manager hierarchy configuration.

**Access Reviews**: When running periodic certification campaigns. Requires Access Reviews licensing.

**Access Profiles**: When using Access Requests for role-based access management. Enable after profiles are defined and assigned.

**Catalog**: For full self-service access requests. Enable when ready for users to request access via configured Access Profiles and Lifecycle Management Integrations.

## Entity Type Visibility Settings

Administrators can use the **Entity Type Visibility** tab to manage the integrations and properties visible to users in Access Hub. This provides fine-grained control over what authorization metadata users can see.

### Integration and Property Management

By default, end users who log in to view their own access can see **all** the Access Graph relationships Veza has discovered. This can include additional metadata either ingested from the source system or generated by Veza, such as:

* Last login dates
* Account IDs and unique identifiers
* Risk scores and security assessments
* System-specific metadata
* Administrative properties

If you need to prevent users from accessing any integration types or authorization metadata, administrators can control visibility settings:

**Integration-Level Controls**

* Toggle visibility of any **Entity Type** for any integration (preventing exposure of sensitive infrastructure details)
* Example: Hide all Google Cloud Folder entities from user view

**Property-Level Controls**

* Toggle visibility of any attribute for an entity type to remove technical identifiers that users don't need to see
* Example: Hide "Organization Name" and "Datasource ID" for all Google Cloud entities

### Property-Level Visibility Control

Within each entity type, administrators have precise control over which properties users can see in their Resources view. Common hidden properties include internal IDs, technical metadata, and sensitive system identifiers. Example use cases might include:

* Hiding AWS account IDs while showing resource names
* Removing timestamp fields that aren't relevant to users
* Showing only business-relevant properties like department, role, or description

**How it works:**

* Each entity type (e.g., "OktaUser", "AWSRole", "GoogleCloudProject") has a configurable list of visible properties
* Properties not in the `displayed_properties` list are hidden from all Access Hub users

## Manager Visibility Settings

The **Manager Visibility** tab controls **which team members appear** in a manager's My Team view. Both toggles on the tab are exclusion filters applied to the set of direct reports: they remove contractors and non-human identities from the list. Neither toggle changes the information shown about a team member who is not excluded.

> **⚠️ Warning: These filters apply only on the Access Graph path.**
>
> If Access Hub's identity provider is set to **LCM Identity**, the **Manager Visibility** tab does not appear at all. More importantly, on that path Lifecycle Management returns direct reports with **no contractor filtering and no non-human identity filtering applied**. An administrator on LCM Identity does not merely lose the tab: the filters do not apply to their organization's My Team views either.
>
> Contractor filtering also depends on the selected property being present on user entities in your identity provider.

### Contractor Filtering

Administrators can hide contractors from appearing in managers' My Team views:

| Setting                     | Description                                                             | Configuration                                                               |
| --------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Hide Contractors Toggle** | When enabled, prevents contractors from appearing in My Team dashboards | Toggle on/off                                                               |
| **Contractor Property**     | Select which IdP property defines contractor status                     | Choose from available IdP properties (e.g., "employeeType", "isContractor") |
| **Contractor Value**        | Define the value that identifies contractors                            | Supports both text values and true/false boolean properties                 |

**Example Configuration:**

* Property: `employeeType`
* Value: `contractor`
* Result: Users with `employeeType = "contractor"` are hidden from managers' My Team views

Access Hub applies an exact equality (`eq`) comparison to the property. It does not support a "contains" match, and it does not support matching more than one value: a single property paired with a single value defines contractor status.

### Non-Human Identity Filtering

Hide service accounts, bot users, and other non-human identities from manager dashboards:

| Setting                              | Description                                                    | Requirements                                                  |
| ------------------------------------ | -------------------------------------------------------------- | ------------------------------------------------------------- |
| **Hide Non-Human Identities Toggle** | When enabled, excludes non-human identities from My Team views | Use Enrichment Rules to define which identities are non-human |

**Use Case:** Prevents managers from seeing service accounts and automated systems in their team access reviews, allowing them to focus on human team members only.

**Configuration Requirements:**

* IdP properties must be synchronized from your identity provider
* Property types supported: String, Boolean
* Non-human identity filtering reads the `identity_type` property on user entities. Many integrations populate `identity_type` natively, and the property can be overridden. Enrichment Rules are one way to define which identities your organization treats as non-human.

## Account Settings (Landing Page)

The **Landing Page** tab holds individual account settings. It currently contains a single preference, **Default Landing Page**, and is structured to support additional individual preferences in the future.

### Landing Page Configuration

**Default Landing Page** is a personal preference, not an administrative control. The product describes it as: "Your default landing page will load first when you sign in."

Two consequences follow:

* **An administrator cannot set this on behalf of anyone else.** Each person chooses their own landing page. An administrator who changes the setting changes only their own experience. Administrators and non-administrators see the same **Landing Page** view.
* **The choice is stored in the browser, not in the tenant.** Veza saves it in browser local storage under the key `__ah-landing-page-<userId>`, scoped to the signed-in user. The preference does not follow a person to another browser, another device, or a private browsing window, and clearing site data removes it.

You can clear the preference at any time to restore the default behavior.

> **ℹ️ Note:** The preference determines only the first page loaded at sign-in. You can still navigate to any other section you are entitled to see.

### Default Landing Page Options

The list of options is filtered to the Access Hub pages the individual viewer is authorized to see, so two people may be offered different choices:

* **My Access**: Your own permissions and access relationships
* **My Team**: Access information for your direct reports
* **Access Reviews**: Your pending access review tasks
* **Access Profiles**: Access Profiles assigned to you or owned by you
* **Catalog**: The self-service access request interface


---

# 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/settings.md?ask=<question>&goal=<endgoal>
```

`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.