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

# Workspace roles

> How workspace roles control what you can do in Pike, and how they interact with public and private project visibility.

# Workspace roles

Pike separates **what you can do** from **what you can see**. Workspace roles control capabilities. For private projects, **membership** controls who can see the project and its contents - see [Private projects](../project/private-projects).

> [!NOTE]
>
> These are two independent systems. A Manager can create and edit projects -
> but only if they can see them. An Admin can always see everything.

***

## Workspace roles

Every workspace member is assigned one or more roles. Roles determine what actions a user can perform across the workspace, regardless of which projects they belong to.

### Role overview

| Role | Purpose |
| - | - |
| **Admin** | Full control over the workspace. Can see all projects, manage members, and configure settings. |
| **Manager** | Can create and manage projects, tasks, and teams - scoped to what they can access. |
| **Basic** | Day-to-day contributor. Can view projects and work on tasks they are assigned to. |
| **Finance** | Access to invoices, expenses, profitability reports, and workspace billing settings. |
| **HR** | Access to people management, time off, contracts, and workforce data. |
| **Guest** | Limited, read-mostly access. Can only use endpoints explicitly marked as guest-accessible. |

> [!TIP]
>
> A user can hold multiple roles. For example, someone might be both a
> **Manager** and **Finance** member if they run projects and handle billing.

### What each role can do

> **Admin**
>
> Admins have unrestricted access to the workspace.
>
> * See **all** projects, including private projects they are not a member of
> * Create, edit, and delete projects and tasks
> * Manage workspace settings, billing, and integrations
> * Invite and remove workspace members
> * Assign and change roles
> * Access all financial and HR data
>
> Admins are the only role that bypasses private project visibility. Use this role sparingly.

> **Manager**
>
> Managers can create and organize work - within the projects they can access.
>
> * Create new projects (public or private)
>
> * Edit and delete projects they have access to
>
> * Create and assign tasks in accessible projects
>
> * View all public projects
>
> * **Cannot** see or modify private projects unless explicitly added as a member
>
> > [!WARNING]
> >
> > Being a Manager does not grant access to all projects. If a project is private
> > and the Manager is not a member, it is completely invisible to them -
> > including its tasks, comments, and attachments.

> **Basic**
>
> The default contributor role for team members doing day-to-day work.
>
> * View all public projects
> * View private projects they are a member of
> * Work on tasks they are assigned to
> * Add comments and attachments to accessible tasks and projects
> * **Cannot** create or delete projects
> * **Cannot** manage workspace settings or members

> **Finance**
>
> Focused on financial operations.
>
> * Access invoices, expenses, and retainers
> * View profitability reports
> * Manage workspace billing and tax settings
> * Subject to the same private project visibility rules as other non-admin roles

> **HR**
>
> Focused on people and workforce management.
>
> * Manage time off requests and balances
> * Access contracts and employee data
> * Manage workspace member settings
> * Subject to the same private project visibility rules as other non-admin roles

> **Guest**
>
> For external collaborators who need limited access.
>
> * Can only access features explicitly marked as guest-accessible (e.g. viewing assigned tasks, viewing assigned projects)
>
> * Cannot access any features that require a specific role
>
> * Subject to private project visibility rules - can only see private projects they are a member of
>
> > [!NOTE]
> >
> > If a user's only role is Guest, they are restricted to guest-accessible
> > endpoints. Combining Guest with another role (e.g. Guest + Basic) gives them
> > the capabilities of both.

> **[Private projects](../project/private-projects)**
>
> Full guide to public vs. private projects, visibility tables, and settings.

***

## Roles vs. project membership

These two systems work together but serve different purposes. Here is how to think about them:

> **Roles**
>
> **What you can do.**
>
> Determined by your workspace role. Controls whether you can create projects, manage members, access financial data, and so on. Applies across the entire workspace.

> **Project membership**
>
> **What you can see.**
>
> Determined by which projects you are added to. Controls whether a private project and its contents are visible to you. Has no effect on public projects.

A few examples to make this concrete:

| Scenario | Outcome |
| - | - |
| Manager, not a member of private project "Alpha" | Cannot see Alpha. Cannot see Alpha's tasks. Cannot edit Alpha. It is as if Alpha does not exist. |
| Basic member, added to private project "Alpha" | Can see Alpha and its tasks. Can work on assigned tasks. Cannot create new projects or manage Alpha's settings. |
| Admin, not a member of private project "Alpha" | Can see Alpha and everything inside it. Can manage it. Admin access overrides membership requirements. |
| Finance member, added to private project "Alpha" | Can see Alpha. Can also access invoices and expenses tied to Alpha. |

***

## FAQ

> **Can a Manager access all projects?**
>
> No. Managers can access all **public** projects and any **private** projects
> they have been explicitly added to. Only Admins can see all projects
> regardless of membership.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.