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

# Roles and Permissions

> PANTA OS uses two workspace-wide roles, Admin and User, plus two visibility levels for assistants: Private and Public.

## What it is

PANTA OS uses a deliberately simple, two-layer permission model.

The first layer is the **role**: every user is either an **Admin** or a **User**. The role determines whether a user can access the Admin Panel and configure the workspace.

The second layer is **assistant visibility**: every assistant created in the workspace is either **Private** or **Public**. Visibility determines who can see and run a given assistant, independent of role.

Together, role and visibility cover everything PANTA OS controls. There are no intermediate roles, no team-admin tier, and no separate "Builder" permission for creating assistants. Any user can build an assistant; only Admins can manage the workspace itself.

## Why it matters

A simple model is easier to operate and easier to audit. Three things are protected without permissions turning into a project of their own.

<CardGroup cols={2}>
  <Card title="Workspace control" icon="shield">
    Only Admins reach the Admin Panel, which is the single place where users, teams, integrations, branding, community posts, and token limits are configured.
  </Card>

  <Card title="Privacy of work" icon="lock">
    Assistants stay private by default. Publishing is an explicit step taken by the creator, not an automatic side effect.
  </Card>

  <Card title="Team-specific scoping" icon="users">
    Public assistants can be assigned to specific teams by Admins, so an HR assistant can stay with HR even though it is technically workspace-wide.
  </Card>

  <Card title="No role sprawl" icon="layers">
    Two roles instead of four keep the model easy to understand. Promotion decisions stay simple.
  </Card>
</CardGroup>

## The two roles

<CardGroup cols={2}>
  <Card title="Admin" icon="shield">
    Full access to the Admin Panel. Manages users (User Management), teams (Team Management), tenant integrations (Integrations), workspace branding and identity (Organization Settings), posts in the community feed (Community Feed), workspace analytics (Analytics), and budget configuration (Token Limits).
  </Card>

  <Card title="User" icon="user">
    Standard end user. Uses chats, assistants, and apps. Creates personal assistants through AI or Manual assistant creation. Reads and flags community posts. Authorizes personal integrations in Settings. No access to the Admin Panel.
  </Card>
</CardGroup>

## What each role can do

| Action                                        | User | Admin |
| --------------------------------------------- | ---- | ----- |
| Use chats, assistants, and apps               | Yes  | Yes   |
| Create personal assistants                    | Yes  | Yes   |
| Upload knowledge files to your own assistants | Yes  | Yes   |
| Read community feed posts                     | Yes  | Yes   |
| Flag community feed posts                     | Yes  | Yes   |
| Create community feed posts                   | No   | Yes   |
| Authorize personal integrations in Settings   | Yes  | Yes   |
| Access the Admin Panel                        | No   | Yes   |
| Manage users (User Management)                | No   | Yes   |
| Manage teams (Team Management)                | No   | Yes   |
| Configure tenant integrations                 | No   | Yes   |
| Edit workspace branding                       | No   | Yes   |
| Set token limits                              | No   | Yes   |
| Assign public assistants to teams             | No   | Yes   |

## Assistant visibility

Visibility is set on the assistant itself, in the Privacy Settings section of the assistant configuration. Two states exist; there is no team-specific or featured tier.

<CardGroup cols={2}>
  <Card title="Private" icon="lock">
    Default state for new assistants. Only the creator can see and run the assistant. Other users in the workspace are not aware that it exists.
  </Card>

  <Card title="Public" icon="globe">
    Visible across the entire workspace. Set by enabling "Make this assistant public" in the Privacy Settings. Once public, Admins can assign the assistant to specific teams through Team Management; users in those teams then see it in their dashboard grid.
  </Card>
</CardGroup>

## How to use it

### Change a user's role

<Steps>
  <Step title="Open the Admin Panel" icon="shield">
    Click Admin at the bottom of the sidebar. Visible to Admins only.
  </Step>

  <Step title="Open User Management" icon="users">
    Switch to the User Management tab.
  </Step>

  <Step title="Edit the user" icon="pen">
    Click the edit icon next to the user in the table. Switch the role between Admin and User.
  </Step>

  <Step title="Save" icon="check">
    The change takes effect immediately. The user's access to the Admin Panel changes with the role.
  </Step>
</Steps>

### Make an assistant available to others

<Steps>
  <Step title="Open the assistant" icon="bot">
    From the dashboard grid or the Assistants section in the sidebar.
  </Step>

  <Step title="Open assistant settings" icon="user-cog">
    Use the edit action to open the assistant's configuration dialog.
  </Step>

  <Step title="Switch to Public" icon="globe">
    Scroll to the Privacy Settings and enable "Make this assistant public". Save with Save Changes.
  </Step>

  <Step title="Assign teams (Admin)" icon="users">
    Once an assistant is public, an Admin can assign it to specific teams through Team Management, in the Assistants tab of the team dialog.
  </Step>
</Steps>

## Key settings and options

<CardGroup cols={2}>
  <Card title="Two roles" icon="user">
    Admin and User. Set per user in User Management.
  </Card>

  <Card title="Two visibility levels" icon="eye">
    Private (default) and Public. Set per assistant in the Privacy Settings.
  </Card>

  <Card title="Team scoping for assistants" icon="users">
    Admins assign public assistants to specific teams in Team Management. This narrows who sees a public assistant without making it private again.
  </Card>

  <Card title="No intermediate roles" icon="x">
    There are no roles for team admin, builder, or auditor. The two-role model covers every administrative scenario in PANTA OS.
  </Card>
</CardGroup>

## Tips and best practices

* Keep the number of Admins small. Enough to cover absences, small enough that every Admin knows what the others are doing.
* Treat Private as the default for new assistants. Make an assistant public only after you have tested it and confirmed it does what you expect.
* If an assistant should reach just one team, make it public and ask an Admin to assign it to that team. Targeted reach is the standard way to scope; do not try to imitate team scoping by keeping an assistant private and sharing the link.
* Review who has Admin access during onboarding and offboarding cycles. The easiest place to do this is the Role column in User Management.

<Tip>
  PANTA OS keeps roles and visibility deliberately minimal. Two roles plus two visibility levels are enough to cover every practical case; more tiers would add complexity without clear benefit.
</Tip>

## Help center

<AccordionGroup>
  <Accordion title="How many roles are there in PANTA OS" icon="user">
    Two: Admin and User. There is no tier for team admin, builder, or auditor.
  </Accordion>

  <Accordion title="Where is the role set" icon="map-pin">
    In the Admin Panel under User Management. Edit the user and select the role.
  </Accordion>

  <Accordion title="Can a user build assistants" icon="bot">
    Yes. Any user can create their own assistants through AI or Manual assistant creation from the dashboard. No separate builder permission is required.
  </Accordion>

  <Accordion title="Can a user post to the community" icon="users-round">
    No. Posts in the community feed are created only by Admins through Admin Panel, Community Feed. End users can read and flag posts, but not post.
  </Accordion>

  <Accordion title="Are there team-specific roles" icon="users">
    No. Roles apply workspace-wide, not per team. Membership in a team does not grant administrative rights within that team.
  </Accordion>

  <Accordion title="What visibility options exist for assistants" icon="eye">
    Two: Private (creator only) and Public (workspace-wide). Public assistants can be narrowed to specific teams by an Admin through Team Management. There is no featured tier.
  </Accordion>

  <Accordion title="Are role changes audited" icon="clock">
    PANTA OS does not currently provide an audit log for role changes. For regular reviews, check the Role column in User Management directly.
  </Accordion>
</AccordionGroup>