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

# Permissions

> See and change what each person can do — base role, per-area admin access, and named roles — from Admin → People → Permissions.

export const InternalNote = ({children}) => {
  const [isInternal, setIsInternal] = useState(false);
  useEffect(() => {
    const user = window.__mintlify_user__;
    if (user?.groups?.includes("internal")) setIsInternal(true);
  }, []);
  if (!isInternal) return null;
  return <div className="internal-note">
      <strong className="internal-note-title">🔒 Internal Note</strong>
      <div>{children}</div>
    </div>;
};

export const RelatedPages = ({pages = []}) => {
  if (pages.length === 0) return null;
  return <>
      <br />
      <strong>Related articles</strong>
      <CardGroup cols={2}>
        {pages.map(page => <Card title={page.title} href={page.href} key={page.href} />)}
      </CardGroup>
    </>;
};

export const RoleBadge = ({roles = []}) => {
  const colorMap = {
    Admin: "yellow",
    Manager: "blue",
    Learner: "green",
    "Co-editor": "purple"
  };
  return <>
      {roles.map(role => <span key={role}><Badge color={colorMap[role] || "gray"} size="sm" shape="pill">{role}</Badge>{" "}</span>)}
    </>;
};

<RoleBadge roles={["Admin"]} />

The **Permissions** view gives you one place to see what every person in your organization can do and to change it. Open it from **Admin → People → Permissions** — a tab next to the legacy **Users** table.

<Note>
  The **Permissions** tab appears only when your organization has it enabled. To use it you need to be a **People** admin — either the **Admin** base role or a **People** area grant. If you don't see the tab, it isn't turned on for your account yet.
</Note>

***

## How access is built

A person's access is the combination of four things. Reading them together tells you exactly what they can do.

| Layer                             | What it controls                                       |         Set here?        |
| --------------------------------- | ------------------------------------------------------ | :----------------------: |
| **Base role**                     | The overall level applied everywhere                   |             ✓            |
| **Per-area admin access**         | Admin access in one area only, on top of the base role |             ✓            |
| **Named roles**                   | Specific capabilities like IT admin or Buyer           |             ✓            |
| **Individually granted features** | Extra features switched on for one person              | Read-only (Juno support) |

A person's effective access in any area is the **higher** of their base role and any per-area grant. Per-area access can only **raise** what someone can do — it never takes access away.

### Base role

Everyone has one base role that applies across the whole platform.

| Level | Base role                | What it means                                    |
| :---: | ------------------------ | ------------------------------------------------ |
|   1   | **Learner**              | Default — access learning and set personal goals |
|   2   | **Instructor**           | Can author and teach content                     |
|   3   | **Manager**              | Supports and tracks direct reports               |
|   4   | **Manager & Instructor** | Both of the above                                |
|   5   | **Admin**                | Full platform administration                     |
|   6   | **Owner**                | Highest level, all permissions                   |

<Note>
  The Permissions view lists people up to **Owner**. Internal and service accounts above that level aren't shown or edited here.
</Note>

### Per-area admin access

Instead of making someone a full Admin, you can give them admin access in **one area only** — for example, someone who manages all your content but nothing else. Each area is a checkbox on the person's detail page. Ticking it grants **admin access in that area**; unticking removes the grant.

### Named roles

Named roles switch on a specific set of capabilities. Two can be assigned here:

* **IT admin** — manage security settings, SSO, and automated user provisioning.
* **Buyer** — approve learning requests and manage credits, payments, and the catalog.

### Individually granted features

Some people have extra features switched on just for them. These appear on the detail page as read-only chips under **Individually granted features**. They're managed by Juno support and can't be changed from this view.

***

## Permission areas

Per-area admin access covers **10 areas**. This is what each one unlocks:

| Area            | What an area admin can manage                                          |
| --------------- | ---------------------------------------------------------------------- |
| **People**      | Users, groups, departments, and custom attributes                      |
| **Content**     | Courses, Journeys, quizzes, SCORM, and the knowledge hub               |
| **Budget**      | Credits, requests, payments, and the catalog                           |
| **Development** | Career paths, skills, competencies, positions, goals, and growth plans |
| **Engagement**  | Surveys, engagement analytics, and the question bank                   |
| **Automations** | Company automations                                                    |
| **Platform**    | Settings, integrations, notifications, AI, modules, security, and SSO  |
| **Events**      | Event sessions, the calendar, and instructor assignments               |
| **Channels**    | Communication channels                                                 |
| **Feedback**    | Feedback menus and features                                            |

<Note>
  Nine of these areas can be granted directly on a person's detail page. **Feedback** is shown for context but can't be granted here — it follows the person's base role.
</Note>

***

## The permissions table

Each row is one person. The table supports server-side search, filter, and sort.

| Column            | What it shows                                                       |
| ----------------- | ------------------------------------------------------------------- |
| **User**          | Name, avatar, and email                                             |
| **Base role**     | The person's overall level                                          |
| **Elevated in**   | Areas and named roles where they have more than their base role     |
| **Manages**       | Who they oversee — direct reports, wider reporting line, and groups |
| **Last activity** | Their most recent activity date                                     |

Above the table, a row of **summary chips** shows every permission configured across your whole organization with a count of how many people hold it. Select a chip to filter the table to those people.

### The "Manages" column

The Manages column summarizes who a person oversees:

* **Direct** — people who report to them directly.
* **In hierarchy** — everyone further down their reporting line.
* **Groups** — permission-granting groups they administer.

Admins and Owners show **All users**, because they manage everyone regardless of reporting lines.

### Search, filter, and export

* **Search** matches on name and email.
* **Filters** narrow by base role, area, and named role.
* **Export** downloads the current filtered view. Exports are capped at **10,000 rows** — if you hit the cap, narrow the filters and export again.

***

## The person detail page

Select any row to open that person's full breakdown.

* **What this person can do** — a checklist of every area and named role. Areas already covered by the person's base role show as checked and disabled, labelled **From their base role** (an Admin already administers every area, so there's nothing extra to grant).
* **Who they manage** — the people they oversee, tagged by reason: **Direct report**, **Reporting line**, or **Managed via {group}**. Long lists show the first 200 people, but the counts always reflect everyone.
* **Individually granted features** — read-only chips, shown only when the person has them.

***

## Changing someone's access

<RoleBadge roles={["Admin"]} />

You need the **Admin** base role to change access. There are two ways to make a change.

### Change the base role

Pick a new base role from the dropdown. Before anything is saved, a **confirmation dialog** shows exactly what will change — the base role itself, any area whose effective access changes, and any named roles added or removed. Confirm to apply.

### Grant an area or named role

Tick or untick an area or named role in the checklist. These changes apply **immediately** — there's no confirmation step.

<Note>
  You can't set someone above your own level or edit someone who's above you. If a change isn't allowed, it isn't applied and you'll see a message that you may not have permission to make it.
</Note>

***

## Who can see and change permissions

* **See the Permissions tab** — People admins (the **Admin** base role or a **People** area grant), once your organization has the feature enabled.
* **Change access** — the **Admin** base role, within the limits above.

<InternalNote>
  Front-end and API both gate on the `can_see_user_permissions_table` flag (default `99` = hidden), scoped to the `people` permission domain, on top of `isAdmin([PermissionDomain.PEOPLE])`. Base roles map to integers 1–6 (Learner…Owner); roles 7/8/10/99 are excluded from the listing. Per-area grants are stored in `domainRoles`; effective level is `max(baseRole, domainRoles[area])`. Only the `it-admin` and `buyer` named roles are admin-assignable — the server strips any others on write. Writes go through the existing `PUT /users/:userId`. Key files: `apps/api/src/api/services/UserPermissions/`, `apps/front/src/features/UserPermissions/`, `usePeopleTabsRoutes.tsx`.
</InternalNote>

<RelatedPages
  pages={[
{ href: "/admin/managing-users", title: "Managing Users" },
{ href: "/admin/roles-and-security", title: "Roles & Security" },
{ href: "/getting-started/roles-and-permissions", title: "Roles & Permissions" },
]}
/>