> ## 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). 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. | 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 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. 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 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. 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 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 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 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 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. 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: **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. **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 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.