> For the complete documentation index, see [llms.txt](https://oten.gitbook.io/identity-support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://oten.gitbook.io/identity-support/user-guide/organization-admin-app/business-owner-default-authority/organizational-structure/hierarchical-access-scoping.md).

# Hierarchical access scoping

### Scope <a href="#scope" id="scope"></a>

This document explains how **hierarchical access scoping** works within an organization using **Organizational Units (Org Units)**.

Hierarchical access scoping defines **where administrative authority and policy scope apply**, based on the organization’s structural hierarchy.

***

### I am new. Where should I start? <a href="#i-am-new.-where-should-i-start" id="i-am-new.-where-should-i-start"></a>

If you are new to hierarchical access scoping:

* Think of the organization as a **tree structure**
* Authority flows **from parent Org Units to child Org Units**
* Administrators only manage the scope they are assigned to

This model helps large organizations control access without granting global permissions.

***

### Purpose <a href="#purpose" id="purpose"></a>

Hierarchical access scoping enables organizations to:

* Limit administrative actions to specific organizational areas
* Apply security policies consistently through inheritance
* Prevent over-privileged administrative access
* Align system access with real-world organizational boundaries

***

### Core Concepts <a href="#core-concepts" id="core-concepts"></a>

#### Organizational Hierarchy <a href="#organizational-hierarchy" id="organizational-hierarchy"></a>

The organization is structured as:

**Organization (Root)**\
→ **Org Unit (Parent)**\
→ **Org Unit (Child)**\
→ **Workspace**

Each level represents a **scope boundary**.

***

#### Access Scope <a href="#access-scope" id="access-scope"></a>

Access scope defines:

* Which users an administrator can manage
* Which Org Units an administrator can view or modify
* Where policies can be applied or overridden

Administrators **cannot act outside their assigned scope**.

***

### When should hierarchical access scoping be used? <a href="#when-should-hierarchical-access-scoping-be-used" id="when-should-hierarchical-access-scoping-be-used"></a>

Hierarchical access scoping is recommended when:

* The organization has multiple departments or business units
* Administrative responsibilities must be segmented
* Different security policies apply to different groups
* You want to avoid global admin privileges

***

### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

Before using hierarchical access scoping:

* Organizational Units must be defined
* Administrative roles must support scoped permissions
* Policy inheritance rules must be understood

***

### I already understand. How do I proceed step by step? <a href="#i-already-understand.-how-do-i-proceed-step-by-step" id="i-already-understand.-how-do-i-proceed-step-by-step"></a>

***

#### 1. Define the Organizational Hierarchy <a href="#id-1.-define-the-organizational-hierarchy" id="id-1.-define-the-organizational-hierarchy"></a>

* Create Org Units that reflect your organization’s structure
* Establish clear parent–child relationships
* Keep the hierarchy as simple as possible

***

#### 2. Assign Administrative Scope <a href="#id-2.-assign-administrative-scope" id="id-2.-assign-administrative-scope"></a>

* Assign administrators to a specific Org Unit
* Define their role within that scope
* Ensure they only see and manage resources within their assigned Org Unit and its children

***

#### 3. Apply Policies at the Appropriate Level <a href="#id-3.-apply-policies-at-the-appropriate-level" id="id-3.-apply-policies-at-the-appropriate-level"></a>

* Apply global policies at the root Org Unit
* Apply more restrictive policies at child Org Units if needed
* Allow policy inheritance unless explicitly overridden

***

#### 4. Manage Users Within Scope <a href="#id-4.-manage-users-within-scope" id="id-4.-manage-users-within-scope"></a>

Administrators can:

* View and manage users within their Org Unit scope
* Assign users to child Org Units
* Enforce policies relevant to their scope

They cannot manage users outside their scope.

***

#### 5. Validate Scope Enforcement <a href="#id-5.-validate-scope-enforcement" id="id-5.-validate-scope-enforcement"></a>

* Test admin access at each Org Unit level
* Verify visibility and permissions
* Confirm that cross-scope access is blocked

***

### Policy Inheritance Rules <a href="#policy-inheritance-rules" id="policy-inheritance-rules"></a>

* Policies applied at a parent Org Unit are inherited by child Org Units
* Child Org Units may override certain policies if allowed
* Overrides never affect parent Org Units

***

### Common Examples <a href="#common-examples" id="common-examples"></a>

#### Example 1: Department-Level Administration <a href="#example-1-department-level-administration" id="example-1-department-level-administration"></a>

* Org Unit: Engineering
* Admin Scope: Engineering
* Access: Engineering + all sub-teams
* No access to Finance or HR

***

#### Example 2: Regional Policy Control <a href="#example-2-regional-policy-control" id="example-2-regional-policy-control"></a>

* Org Unit: APAC
* Policy: Geo-based access restriction
* Scope: Applies only to APAC users

<br>