# Settings

## Overview

Administrators can use the **Access Hub** > **Settings** page to customize the behavior and appearance of Veza Access Hub. These settings control which features are available to users and what information they can see when accessing their authorization data.

To view and manage settings, navigate to **Access Hub** (in the Products section of the navigation sidebar) and click the **Settings** gear icon.

> **ℹ️ 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 allows administrators to control what information managers see when viewing their team members in the My Team dashboard. This helps focus managers on relevant team members and reduces noise from service accounts or contractors.

> **⚠️ Warning:** Manager Visibility settings require proper IdP property configuration and may depend on Enrichment Rules for optimal functionality.

### 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") |
| **Property 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"` will be hidden from managers' My Team views

### 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, filters out non-human identities from My Team views | Requires Enrichment Rules configuration |

**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 properly synchronized from your identity provider
* Property types supported: String, Boolean
* Non-human identity filtering requires pre-configured Enrichment Rules

## Account Settings (Landing Page)

Use the **Landing Page** tab to configure individual user account settings. Currently, this section focuses on default landing page behavior, but is structured to support additional individual user preferences in the future.

### Landing Page Configuration

Control what users see first when they log into Access Hub. This setting determines which page loads by default, helping you direct users to the most relevant information for their role.

> **ℹ️ Note:** While users can navigate to other sections using the navigation sidebar, the default landing page determines the initial experience for first-time visitors and subsequent logins.

### Default Landing Page Options

Choose which page users see immediately after signing in. Customize this based on your primary use cases and licensed Veza products:

* **My Access**: Shows users their own permissions and access relationships (recommended for most users)
* **My Team**: Displays team access information (for organizations where managers are the primary users)
* **Access Reviews**: Opens directly to pending review tasks (for compliance-focused deployments)
* **Access Profiles**: Shows assigned and owned profiles (for role-based access environments)
* **Catalog**: Opens the self-service request interface (for organizations emphasizing self-service)


---

# 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/access-hub/settings.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.
