# Users and Permissions PAI has four user roles. 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 1. Go to **Settings → Users** 2. Click **Add User** 3. Choose the account type: - **Workspace User** — grants login access. Select this for anyone who needs to work in PAI directly. - **Staff Record** — no login access, but the person can be assigned to projects and call sheets. Select this for contacts you want to track without giving them app permissions. 4. Fill in the details. Both types require email, first name, and last name. Phone and title are optional. 5. For Workspace Users, also select a **Role** and optionally set an **Account Expiration** date. The right panel previews the permissions for the selected role as you configure them. Click **Create & Invite User** — an invitation email goes out immediately so the user can activate their account. 6. For Staff Records, click **Create Staff Record**. No invitation is sent. > [!tip] > If you want to finish project assignments before a new workspace user receives their welcome email, you can create them as a Staff Record first, then convert or recreate them as a Workspace User when you're ready to give them access. --- ## User Roles | 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. --- ## 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, 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. 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.