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

# Access Core Concepts

> Core concepts for configuring access controls in Serval

This guide explains the key concepts you'll use when setting up access management in Serval.

***

## Access Layers

Understanding how Serval organizes access helps you configure it effectively.

**Apps, Resources, and Roles**

Serval organizes access in a three-level hierarchy:

| Layer           | What it means                                                                        | Examples                                   |
| :-------------- | :----------------------------------------------------------------------------------- | :----------------------------------------- |
| **Application** | The applications you connect to Serval.                                              | GitHub, Slack, AWS, Okta, Linear           |
| **Resource**    | Groupings within apps. Apps without subdivisions use a single "App Access" resource. | GitHub teams, Slack channels, AWS accounts |
| **Role**        | Access levels within resources.                                                      | Admin, Member, Viewer, Owner               |

Every app has a default resource called "App Access" that controls baseline access to the application itself. You can then create custom resources for finer-grained control.

<Tip>
  **Example:** In GitHub, "App Access" controls whether someone can use GitHub at all. A custom resource for the "Engineering" team controls who can access that specific team's repositories, with roles like "Member" or "Maintainer."
</Tip>

## **Profiles vs. Policies vs. Provisioning**

Similar-sounding terms do different things:

* [**Access Profiles**](https://docs.serval.com/sections/access-management/configuration/access-profiles) = Who can request access (eligibility)
* [**Access Policies**](https://docs.serval.com/sections/access-management/configuration/access-policies) = Under what rules they can request it (approval, duration, justification)
* [**Provisioning**](https://docs.serval.com/sections/access-management/configuration/access-provisioning) = How am I going to get the user into that particular role

Think of profiles as the gate ("Can I even ask?") and policies as the rules once you're through the gate ("What do I need to provide?").

**Application Role Example**: A developer requests GitHub (application) --> Member (role)

**Resource Role Example:** A developer requests GitHub (application) → Engineering Team repo (resource) → Write access (role)

***

## Role Configuration

Access control in Serval uses three components that work together:

<Card>
  Access Profile → Access Policy → Provisioning Method

  (Who can request) → (What rules apply) → (How access is granted and removed)
</Card>

<Steps>
  <Step title="Profile checks eligibility">
    When a user requests a role, Serval checks if they belong to a group in the Access Profile
  </Step>

  <Step title="Policy applies rules">
    If eligible, the Access Policy determines duration, justification requirements, and approval workflow
  </Step>

  <Step title="Provisioning grants access">
    Once approved, the Provisioning Method actually grants the access (via IdP group, API, workflow, or manual task)
  </Step>

  <Step title="De-provisioning removes access">
    Once the duration of access from the access policy has expired, the user is removed from role
  </Step>
</Steps>

***

## Quick Reference

<AccordionGroup>
  <Accordion title="What's the difference between a resource and a role?">
    A **resource** is what you're accessing (e.g., the Engineering Team in GitHub).

    A **role** is the permission level within that resource (e.g., Write access to the Engineering Team).
  </Accordion>

  <Accordion title="Do I need to set up resources for every app?">
    No. Simple applications can use just "App Access" as a single resource. Only create additional resources if you need to manage access to specific teams, channels, or subdivisions.
  </Accordion>

  <Accordion title="Can I reuse profiles and policies across roles?">
    Yes. Profiles and policies are designed to be reused. Create them once and apply them to multiple roles for consistency.
  </Accordion>

  <Accordion title="What if my provisioning method changes?">
    You can update the provisioning method for a role at any time. This only affects future access requests. Existing access continues using the original method.
  </Accordion>
</AccordionGroup>