# Understanding Roles

Roles define what a user can do in AccessIQ. Each role contains a set of permissions that control access to features and data.

## Authorization Model

AccessIQ uses three complementary authorization strategies:

| Strategy                                           | When It Applies                                                                                                                                                                             |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **RBAC** (Role-Based Access Control)               | Tenant-wide access decisions — "Can this user access admin features?"                                                                                                                       |
| **HRBAC** (Hierarchical Role-Based Access Control) | Organization-scoped access — a role at a parent org inherits to all descendant orgs. Org-scoped entities (apps, feature flags, accounts) are only visible to users with access to that org. |
| **ABAC** (Attribute-Based Access Control)          | Conditional policies — time-based access, IP restrictions, MFA requirements, resource ownership checks.                                                                                     |

HRBAC is the primary model for multi-org tenants. When a user is assigned a role at the Engineering division, they automatically have that role in all teams under Engineering.

## Built-in Roles

AccessIQ comes with these default roles:

| Role               | Priority | Description                                                                                                     |
| ------------------ | -------- | --------------------------------------------------------------------------------------------------------------- |
| **Owner**          | 100      | Full access to everything. System role — cannot be assigned via invitations.                                    |
| **Admin**          | 80       | Administrative access. System role — cannot be assigned via invitations.                                        |
| **Admin Helpdesk** | 80       | Support role with elevated access. Can impersonate users and perform cross-tenant operations (platform admins). |
| **Manager**        | 60       | Can manage users and organizations within their scope                                                           |
| **Support**        | —        | Can view users and handle support tasks                                                                         |
| **Auditor**        | —        | Read-only access focused on audit and compliance                                                                |
| **Member**         | 40       | Standard user with basic access (default role for new users)                                                    |

Role priority determines impersonation constraints — an admin can only impersonate users with a lower priority role.

## System Roles vs. Assignable Roles

* **System roles** (Owner, Admin, Admin Helpdesk) are protected — they don't appear in invitation dropdowns and can only be assigned by other system-role holders
* **Assignable roles** (Manager, Support, Auditor, Member, and custom roles) can be assigned through invitations and user management
* **Composite roles** can inherit permissions from multiple other roles. Inherited permissions are shown in purple in the Permission Matrix; direct permissions in green.

## Role Scope

Roles can apply at different levels:

* **Tenant-wide** — The role applies across the entire tenant (RBAC)
* **Organization-scoped** — The role applies only within a specific organization and its descendants (HRBAC). Assigned when adding a user to an org or team.

A user can have different roles in different organizations. For example, they might be a Manager in the Engineering team but a Member in the Sales team.

### How Permissions Flow Through the Organization Hierarchy

The diagram below shows how organization-scoped roles inherit downward. A user assigned a role at a parent organization automatically holds that role in every team beneath it — but has no access to sibling organizations or their children.

```mermaid
graph TD
    Acme["Acme Corp (Tenant)"]

    Acme --> Eng["Engineering Division"]
    Acme --> Sales["Sales Division"]

    Eng --> Platform["Platform Team"]
    Eng --> Mobile["Mobile Team"]
    Sales --> Enterprise["Enterprise Team"]
    Sales --> SMB["SMB Team"]

    subgraph access_yes ["Sara's access (Org Admin @ Engineering)"]
        direction TB
        Eng
        Platform
        Mobile
    end

    subgraph access_no ["No access — sibling division"]
        direction TB
        Sales
        Enterprise
        SMB
    end

    style access_yes fill:#d4edda,stroke:#28a745,color:#000
    style access_no fill:#f8d7da,stroke:#dc3545,color:#000
```

**Key takeaway:** Sara is an Org Admin in Engineering, so she can manage users and settings in Engineering, Platform, and Mobile. She cannot see or manage anything in the Sales division — even though both divisions belong to the same tenant.

## Default Role

One role is marked as the **default** — this is automatically assigned to new users who sign in via SSO or are provisioned through Directory Sync without a pending invitation. Typically this is the "Member" role.


---

# 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://accessiq.gitbook.io/accessiq-docs/roles-and-access-control/understanding-roles.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.