# Users and Permissions PAI has two account types — **Workspace User** and **Staff Resource** — and four user roles that apply to the former. The role you assign sets a user's baseline — what they can see and do across the entire workspace. On top of that baseline, per-user **permission overrides** let you grant or revoke individual capabilities for a specific person. This page covers the role model, the override system, the **View Staff Rates** permission that keeps in-house staff costs confidential, how to add and remove users, and how to control access to specific projects. --- ## Adding Users Go to **Settings → Users** and click **Add User**. The first step asks which of two account types you're creating: - **Workspace User** — login access with permissions to manage projects and more. Choose this for anyone who needs to work in PAI directly. - **Staff Resource** — assignable to projects, expenses, and call sheets, with optional login access for logging hours. Choose this for people whose only involvement is being scheduled, costed, or reporting their own time. Both types require email, first name, and last name; phone and title are optional. ### Workspace Users Select a **Role** — the right panel previews that role's permissions as you change the selection — and optionally set an **Account Expiration** date. Click **Create & Invite User** and an invitation email goes out so the person can activate their account and complete their profile. ### Staff Resources A Staff Resource has no role and no permission set, because there's almost nothing for permissions to govern. They can be assigned to projects, to budget expense lines, and to call sheets, which is what makes them usable as a scheduled, costed person without giving them the run of the workspace. The **Send Invite to Log Hours** dropdown controls whether they get login access at all, and offers two choices: **Invite**, or **Don't Invite** (the default). Choose **Invite** and they can sign in — but the entire app surface they receive is [HQ](../00-Understanding-PAI/Navigating-PAI.md#the-dashboard) with the **Log Hours** widget on it, so they can report time against in-house expense lines assigned to them and nothing else. No projects, no budgets, no settings. See [Hours Reporting](../04-Executing-the-Job/Hours-Reporting.md). Choose **Don't Invite** and they're created as a record with no login at all — still fully assignable and costable, just with no way in. That's the case covered below. Click **Create Staff Resource** to finish. ### Users Created Without an Invitation A user in the list who has never been invited is a **staff record** — a real record you can assign and cost, attached to no login. Creating a Staff Resource with **Don't Invite** is how one comes about; Workspace Users are invited as part of being created, so they don't arrive in this state. A staff record isn't permanent. Open the person's record later and send the invite whenever you want to give them access to log their hours. > [!note] > "Staff record" and "Staff Resource" are different things, and the similarity is unfortunate. A **Staff Resource** is an account type you choose when creating the user. A **staff record** is the state of not having been invited. An invited Staff Resource is still a Staff Resource — it just isn't a staff record any more. <!-- VERIFY: The Staff Resource panel in-app reads "This user won't have login access to PAI" even when Invite is selected. Documented per actual behavior (invite grants HQ + Log Hours), not per that copy. --> --- ## User Roles Roles apply to Workspace Users. A Staff Resource doesn't carry one — their access is fixed at hours reporting, as described above. | Permission | Workspace Owner | Workspace Admin | Project Admin | Guest | |---|---|---|---|---| | **Project visibility** | All projects | All projects | Only projects created or assigned to | Only assigned projects | | **Campaign access** | Full | Full | Only campaigns they created | None | | **Rate card** | Can modify | Can modify | No access | No access | | **User management** | All users including admins and owners | All users except admins and owners | None | None | | **Project sharing** | Can assign any user | Can assign any user | None | None | | **Financial visibility** | Full | Full | Full | Limited | | **Organization Settings** | Full | Full | None | None | | **Payroll / AP access** | Organization-wide | Organization-wide | Assigned projects only (via project tab) | None | | **Contacts** | Full | Full | Full | Limited view | | **Tags** | Create, modify, apply | Create, modify, apply | Apply existing only | Apply existing only | | **View Staff Rates** | On by default | Off (Owner can grant) | Off (Owner can grant) | Off | ### Workspace Owner Full control over the workspace — all users, all projects, all settings. Can modify or revoke access for any user including other owners and admins. Typically limited to account holders or senior administrators. ### Workspace Admin Extensive administrative access to all projects and settings. Can manage most users but cannot modify or revoke access for other admins or owners. The appropriate role for operations managers and department leads who need full visibility without owner-level control. ### Project Admin Focused access to the projects they created or have been assigned to. Full financial visibility on their projects. Cannot access organization settings, manage other users, or see projects they haven't been assigned to. The standard role for producers and project managers. ### Guest The most restricted role. Can only access projects they've been explicitly assigned to, with limited financial visibility — specifically, they cannot see the estimate, opportunity, or financial tabs, which means they don't have visibility into the external total or overall margin. Designed for external collaborators or team members who need to work within a project (budget, call sheets, post) without seeing client-facing financial details. > [!note] > Enterprise accounts can request additional custom roles with tailored permission sets. Contact [email protected] for details. --- ## The Workspace User Record Each workspace user has a record under **Settings → Users → (user)**. Beyond the basic details and role, the record carries three tabs that control what the person costs, what they can access, and what's on their plate: - **Custom Rates** — the user's staff rate card: a default hourly rate and an item-based rate card, each with external and internal values. This is what the person bills and costs when assigned to an estimate or budget line. The internal values are gated by View Staff Rates (below). See [Staff Rates](./Staff-Rates.md) for the full breakdown. - **Permissions** — per-user overrides on top of the role baseline (below). - **Calendar** — everything the user is scheduled on: events and tasks they're a part of or assigned to, plus the estimate line items and budget expense lines they're assigned to. Date-range assignments made through the **Dates** field on a line feed this calendar, so a person's record shows their committed time across projects. **Every user in the workspace carries a Custom Rates tab** — Workspace Users and Staff Resources alike, invited or not. Anyone who can be assigned to a line needs rates behind them, so the rate card doesn't depend on having a login. --- ## Per-User Permissions The **Permissions** tab manages overrides for an individual user, on top of what their role already grants. It carries two toggles: - **View Staff Rates** — view and edit the internal side of in-house staff rates, on estimates, budgets, and the user-record Custom Rates tab (see below). - **View Insights Report** — access the [Insights](../06-Financial-Visibility/Insights.md) report. > [!important] > **View Insights Report depends on View Staff Rates.** You can't enable Insights on its own — View Staff Rates must be on as well. This is because Insights is built on combined in-house and out-of-pocket totals, which expose in-house internal costs; granting Insights without Staff Rates would leak the numbers the gate exists to protect. --- ## View Staff Rates In-house staff costs reveal what your organization actually pays to deliver work in-house — and the margin it makes on internal labor. That's sensitive financial information, so PAI keeps it behind its own permission and lets you decide who can see it. **View Staff Rates** controls who can see and edit the *internal* side of in-house lines — on estimates, on budgets, on the Expenses report, on a project's [Log Hours](../04-Executing-the-Job/Hours-Reporting.md) page, and on the user-record Custom Rates tab. **It's on by default for Owners only.** Workspace Admins, Project Admins, and the staff members themselves do not see in-house internal rates unless the permission is granted to them. **Only an Owner can grant it** — an Admin cannot enable it for themselves or others. A staff member cannot see their own internal rate. **What's hidden when the permission is off.** On **in-house lines only**, these fields show an eye-slash icon in place of a value: - Internal Rate - Internal Subtotal - Internal Fringe - Internal Total - Margin $ - Margin % **What stays visible.** Everything else remains fully accessible. On in-house lines, users without the permission still see the external rate, external subtotal, external total, and all logistics — hours, days, flat amounts, Assigned To, and Dates — so they can run the external and scheduling side of internal work without ever seeing what it costs the organization. And on **out-of-pocket lines, nothing is hidden**: the internal (vendor cost) and margin stay visible to everyone, exactly as before. The gate is specific to in-house internal costs. > [!important] > "Internal" means the cost side on every line. On out-of-pocket lines that's the vendor cost, which everyone sees. View Staff Rates hides only the internal values on **in-house** lines. If a user reports they can see internal numbers on some lines but not others, this is why — and it's working as intended. One place the permission has no bearing: [Hours Reporting](../04-Executing-the-Job/Hours-Reporting.md). The reporting modal deals only in hours and shows no rates, subtotals, or totals to anyone, whether they hold View Staff Rates or not. The permission also reaches beyond line items. Without it, a user loses access to the **Custom Rates** tab (and, in some cases, the **Permissions** tab) on user records, and to reporting surfaces that present blended in-house and out-of-pocket figures — most notably [Insights](../06-Financial-Visibility/Insights.md), which is built on combined totals. The [Expenses](../06-Financial-Visibility/Expenses.md) report stays available but eye-slashes in-house internals the same way the budget does. --- ## Removing Users To remove a user, access their record in **Settings → Users** and use the delete action in the table. Deletion immediately revokes all access to your organization and any projects they were assigned to. > [!note] > Removing a user archives their record rather than permanently deleting it — nothing is ever fully deleted. An archived user can't log in and loses all access, but their past contributions stay attributed to them, preserving the history of their actions in project records. Because the record is retained, you can restore (un-revoke) a user at any time to give their access back. --- ## Assigning Access to Projects For users with restricted roles (Project Admin or Guest), you control which projects they can see through one of three assignment methods. ### By Project Assign a user directly to a specific project. Navigate to the project and add them as a contact or collaborator. Changes take effect immediately. Workspace Owners and Admins don't need project assignments — they can see everything. ### By Campaign Assign a user to a Campaign. They'll automatically gain access to all projects within that campaign. Note: campaign-assigned users can see the individual projects but cannot view the campaign itself. ### By Client Assign a user to a client record and they'll automatically gain access to all existing and future projects associated with that client. 1. Navigate to the client record 2. Open the **Assignments** tab 3. Type the user's name to assign them This is the most efficient method for team members who consistently work with a specific client — account managers, dedicated creative teams, or producers who run all productions for a particular brand. It eliminates the need to manually assign new projects as they're created. --- ## Authentication PAI requires two-factor authentication for all users by default. After entering their password, users receive a one-time code to their email to complete login. Organizations using Single Sign-On (SSO) bypass the standard login flow — users are redirected to their identity provider instead. --- ## Activity Logging PAI maintains an audit log of user actions, including document creation and modification, estimate version updates, and invoice approvals. This provides an accountability trail across the workspace.