> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opigno.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding Hierarchy Inheritance

> Learn how content inheritance works in Opigno Enterprise hierarchies and how assignments cascade through organizational levels

## Overview

In Opigno Enterprise, hierarchy inheritance determines how content visibility and access flow through your organizational structure. When you assign content to a hierarchy level, it doesn't exist in isolation—it follows an inheritance model that affects what users can see based on their position in the hierarchy.

Understanding how inheritance works is crucial for:

* Planning effective content distribution strategies
* Ensuring users see the right content for their role
* Maintaining security and content isolation between departments
* Creating efficient training programs that leverage organizational structure

<Info>
  Content assigned to a hierarchy level automatically cascades down to all sub-levels beneath it. This creates a powerful distribution mechanism where higher-level content is accessible to everyone below, while lower-level content remains restricted to specific teams.
</Info>

***

## How Inheritance Works

Hierarchy inheritance in Opigno Enterprise follows a top-down model where content flows from parent levels to child levels, but never sideways between sibling branches.

### Example Organizational Structure

To illustrate how inheritance works, consider this typical company hierarchy:

```
Company (Top Level)
  ├─ Sales Department
  │   ├─ Sales Team A
  │   └─ Sales Team B
  └─ Engineering Department
      ├─ Frontend Team
      └─ Backend Team
```

This structure demonstrates:

* **One top level**: "Company" serves as the root learning area
* **Two main branches**: Sales and Engineering departments
* **Four sub-teams**: Each department has specialized teams beneath it

***

## The Three Rules of Inheritance

<AccordionGroup>
  <Accordion title="Rule 1: Top-Down Access (Cascading Inheritance)">
    Content assigned to a higher level automatically becomes visible to all users at lower levels within the same branch.

    **Example: Assignment at "Sales Department":**

    * ✓ Visible to users in "Sales Department"
    * ✓ Visible to users in "Sales Team A"
    * ✓ Visible to users in "Sales Team B"
    * ✗ NOT visible to "Engineering Department" users
    * ✗ NOT visible to "Frontend Team" or "Backend Team" users

    **Why this matters:**
    This allows you to create department-wide training programs that automatically reach all teams within that department, without manually assigning to each sub-level.

    **Practical use case:**
    A "Sales Best Practices" training assigned to the Sales Department will be available to both Sales Team A and Sales Team B, ensuring consistent training across all sales personnel.
  </Accordion>

  <Accordion title="Rule 2: Isolation Between Branches (Sibling Separation)">
    Content assigned to one branch is completely isolated from sibling branches at the same level. There is no horizontal visibility between parallel organizational units.

    **Example: Training assigned to "Sales Team A":**

    * ✓ Visible to "Sales Team A" users only
    * ✗ NOT visible to "Sales Team B" users (sibling)
    * ✗ NOT visible to "Engineering Department" users
    * ✗ NOT visible to any engineering teams

    **Why this matters:**
    This isolation ensures that department-specific or team-specific content remains confidential and relevant only to the intended audience. Engineering teams won't see sales-specific materials, and vice versa.

    **Practical use case:**
    "Sales Team A" might have specialized training on a specific product line or territory that shouldn't be visible to "Sales Team B" who handles different products or regions.
  </Accordion>

  <Accordion title="Rule 3: No Assignment (Global Content)">
    Content without any hierarchy assignment is globally accessible across all learning areas and organizational levels.

    **Common use cases for global content:**

    * Company-wide announcements and updates
    * General onboarding training for all new employees
    * Universal policies and procedures (HR, compliance, safety)
    * Shared resources like company handbooks or style guides
    * Organization-wide events and celebrations

    **Why this matters:**
    Not all content needs to be restricted. Some training and resources should be available to everyone regardless of their position in the hierarchy.

    **Practical use case:**
    A "2025 Company Goals and Vision" training or "Annual Compliance Training" should be available to all employees across all departments and teams.
  </Accordion>
</AccordionGroup>

***

## Practical Examples

Understanding how inheritance works in real scenarios helps you plan your content assignments effectively.

### Example 1: Company-Wide Training

**Scenario:** Annual compliance training required for all employees

**Assignment:**

* Training: "2025 Compliance & Ethics"
* Hierarchy Level: Company (Top Level) or No Assignment
* **Result:** Every user in the organization can access this training

**Visibility:**

* Company level ✓
* Sales Department ✓
* Sales Team A ✓
* Sales Team B ✓
* Engineering Department ✓
* Frontend Team ✓
* Backend Team ✓

***

### Example 2: Department-Level Training

**Scenario:** Sales methodology training for the entire sales organization

**Assignment:**

* Training: "Advanced Sales Techniques 2025"
* Hierarchy Level: Sales Department
* **Result:** All sales teams can access, engineering teams cannot

**Visibility:**

* Company level ✗
* Sales Department ✓
* Sales Team A ✓
* Sales Team B ✓
* Engineering Department ✗
* Frontend Team ✗
* Backend Team ✗

***

### Example 3: Team-Specific Training

**Scenario:** Specialized training for frontend developers only

**Assignment:**

* Training: "React 19 New Features"
* Hierarchy Level: Frontend Team
* **Result:** Only frontend team members see this training

**Visibility:**

* Company level ✗
* Sales Department ✗
* Sales Team A ✗
* Sales Team B ✗
* Engineering Department ✗
* Frontend Team ✓
* Backend Team ✗

<Tip>
  When planning content assignments, start with the lowest (most specific) level that needs access. You can always assign to a higher level if more teams need the content, but it's harder to restrict access once content is assigned too high in the hierarchy.
</Tip>

***

## Strategic Planning with Inheritance

### Content Distribution Strategy

When planning your hierarchy assignments, consider this approach:

<Steps>
  <Step title="Identify Your Audience">
    Determine who needs access to this content. Is it everyone, a specific department, or just one team?
  </Step>

  <Step title="Find the Common Ancestor">
    Locate the lowest hierarchy level that includes all intended users. This is where you should assign the content.
  </Step>

  <Step title="Verify Exclusions">
    Confirm that users who shouldn't have access are in different branches that won't inherit the content.
  </Step>

  <Step title="Test the Assignment">
    After assignment, verify with test users at different levels to ensure inheritance works as expected.
  </Step>
</Steps>

***

### Common Assignment Patterns

<CardGroup cols={2}>
  <Card title="Universal Training" icon="globe">
    **Pattern:** No hierarchy assignment or top-level assignment

    **Best for:** Onboarding, compliance, company-wide initiatives

    **Visibility:** Everyone
  </Card>

  <Card title="Department Training" icon="building">
    **Pattern:** Assign to department level

    **Best for:** Department-specific processes, shared team knowledge

    **Visibility:** All teams within the department
  </Card>

  <Card title="Team Training" icon="users">
    **Pattern:** Assign to specific team level

    **Best for:** Role-specific skills, specialized knowledge

    **Visibility:** Single team only
  </Card>

  <Card title="Multi-Department Training" icon="sitemap">
    **Pattern:** Assign separately to multiple department branches

    **Best for:** Cross-functional skills needed by specific departments

    **Visibility:** Selected departments only
  </Card>
</CardGroup>

***

## Impact on User Experience

Understanding how users experience inheritance helps you create better learning environments.

### What Users See

Users at any hierarchy level will see:

1. Content assigned to their specific level
2. Content from all parent levels above them
3. Content with no hierarchy assignment (global)

**They will NOT see:**

* Content from sibling branches
* Content from child levels below them (unless they're also assigned to those levels)
* Content from unrelated hierarchy branches

<Info>
  Users don't need to understand the inheritance model—they simply see the content relevant to their position. The system handles the visibility logic automatically.
</Info>

***

### Moving Users Between Levels

When a user moves from one hierarchy level to another (e.g., promotion, transfer), their content access changes immediately:

<Warning>
  If a user has in-progress trainings from their old hierarchy level and is moved to a new level where that content isn't visible, they may lose access to those trainings. Plan user moves carefully to avoid disrupting active learning.
</Warning>

**Best practices:**

* Allow users to complete critical in-progress trainings before moving them
* Assign content to higher levels if multiple teams need ongoing access
* Consider temporarily assigning content to both old and new levels during transitions

***

## API Integration

For programmatic management of hierarchy assignments through Zapier or custom integrations:

<CardGroup cols={2}>
  <Card title="Assign Training to Level" icon="link" href="/OpignoEnterpriseAPI/AssignTrainingToLevel">
    API endpoint to programmatically assign trainings to hierarchy levels
  </Card>

  <Card title="Unassign Training from Level" icon="link-slash" href="/OpignoEnterpriseAPI/UnassignTrainingFromLevel">
    Remove training assignments from hierarchy levels via API
  </Card>

  <Card title="Assign Taxonomy to Level" icon="tag" href="/OpignoEnterpriseAPI/AssignTaxonomyTermToLevel">
    API endpoint for assigning taxonomy terms to hierarchy levels
  </Card>

  <Card title="User Context Management" icon="user-gear" href="/OpignoEnterpriseAPI/UserContextManagement">
    Manage user assignments to hierarchy levels programmatically
  </Card>
</CardGroup>

***

## Learn More

<CardGroup cols={2}>
  <Card title="Set Up Hierarchy Levels" icon="sitemap" href="/hierarchy-management/configuration-guide/setup-hierarchy-levels">
    Learn how to create and structure hierarchy levels in your organization
  </Card>

  <Card title="Assign Content to Levels" icon="link" href="/hierarchy-management/configuration-guide/assign-content-to-levels">
    Step-by-step guide for assigning trainings and content to hierarchy levels
  </Card>
</CardGroup>