--- title: "Admin console" slug: admin/overview url: https://projectri.com/docs/admin/overview section: admin audience: admin app_route: "/[slug]/admin" mobile: "/admin/overview" updated: 2026-09-08 source: Projectri documentation --- # Admin console The landing page of the admin console — the state of the whole company on one screen, and the map of every setting behind it. ![Admin console](https://projectri.com/docs-shots/admin-overview.png) ## What it is The admin console is the part of Projectri that sets the rules for everyone else — who is in the workspace, what each role may do, how the working week is defined, what the plan costs, what the integrations are wired to. Its landing page is a single dashboard of the company as a whole, and the left rail beside it is the map of everything the console can change. This screen is deliberately not the member dashboard with a wider filter. Your home screen answers "what is on my plate". This one answers "what is the state of the company", so it leads with the things only an admin can act on. ## How to get there The console lives at `//admin`. There is no username in the URL — the console belongs to the company, not to whichever admin opened it, so two admins share one link. Reaching it needs the **ADMIN** role. A non-admin who follows the link is sent back to their own home screen rather than shown a refusal, because the console is not theirs. Two subtrees are the exception and open on a permission instead of the role: **Security** on `security.view`, and the **Knowledge base** authoring screens on `kb.create`. The role is not a cross-tenant permission. Being an admin of one workspace grants nothing in another — every route resolves the caller's membership of the workspace it is acting on, and an id from a workspace you do not belong to matches nothing. ## How to use it ### Read the state of the company 1. Open `//admin`. Everything arrives in one request, so the page settles in one step rather than nine. 2. The six tiles across the top are **Active projects**, **Open tasks**, **Overdue**, **Members**, **Hours logged** and **Budget used**. Four of them are links — clicking Members opens the members screen, Hours logged opens Workload, Budget used opens Billing, Active projects opens the project list. 3. **Overdue** turns red as soon as it is above zero. **Budget used** turns red at 90% or more. A workspace with no budgets set anywhere reads `—`, never `0%`. 4. **Throughput** draws tasks created against tasks completed over the last 28 days. Both lines share one scale, so they can be read against each other. 5. **Work by status** and **Open work by priority** are the same 28-day window read as proportions. 6. **Upcoming milestones** carries the RAG colour and the percentage complete of each; anything past its target date is marked overdue in red. 7. **Recent admin activity** is the last handful of audited actions with the person who took each. **Audit log** at the top of that card opens the full trail. ### Find the right settings screen The rail groups the console into six sections, and the grouping is the fastest way to find something: - **Organization** — Overview, [Company](/docs/admin/company), [Branches](/docs/admin/branch), [Departments](/docs/admin/departments), [Settings](/docs/admin/settings), Sandboxes. - **People** — [Members](/docs/admin/members), [Teams](/docs/admin/teams), [Roles](/docs/admin/roles), [Permissions](/docs/admin/permissions), [Workload](/docs/admin/workload), Skills, [Account closures](/docs/admin/account-requests). - **Insight** — Reports, Financials. - **Work** — [Workspaces](/docs/admin/workspaces), Workflow, Automation, Agents, Approvals, Meeting notes, SLAs, Escalation, Customer status, Knowledge base, Notification channels, Integrations, Webhooks. - **Money** — Invoicing, Receivables, Purchasing, Billing, AI spend, Finance setup. - **Security** — Security, Identity, Audit Log, Privacy, Warehouse export. ### Set a workspace up from scratch The order matters, because each step is the input to the next: 1. **Settings → Region.** Pick the country. It provisions the working week, the timezone and the date format, and every capacity and utilisation figure in the product divides by that working week. 2. **Departments**, then **Teams**. A team must belong to a department, so the departments have to exist first. 3. **Members.** Invite people and give each a role. 4. **Permissions.** Adjust what each role grants, or override one person. 5. **Workload.** Set each person's weekly capacity hours. ## What it affects - **Nothing on this page writes anything.** The overview is read-only; every figure on it is produced by a screen elsewhere in the console or in the workspace. - **The rail is not filtered by permission.** Every console module is listed to everybody who can reach the console, which is why the console gate is the ADMIN role rather than a per-row check. - **A guarded page is not a guarded route.** The console shell checks the role server-side before any HTML is delivered, and every `/api/workspace/*` handler behind it runs its own check as well. Losing the console does not leave an API open behind it. - **A role change is felt immediately.** The server reads a member's role from their membership row rather than from their session token, so an admin who is demoted stops being answered as an admin at once, and their open tab is told to re-read its permissions rather than keeping the console until the token expires. ## On mobile The Expo app has an **Admin** hub with the sections that block somebody else while you are away from a laptop: Members and invites, Teams, [Account closures](/docs/admin/account-requests), Security, Workspace settings, Agents, Automation, [Workload](/docs/admin/workload), Workspaces and the audit trail. The overview dashboard itself is at `/admin/overview` and reads the same single payload the web page does. The rest of the console is web only — a permissions matrix, a billing profile and an integration's OAuth handshake are desk work. The phone checks the ADMIN role once, when you enter the admin group. Switching to a workspace where you are only a member while standing on an admin screen drops you out of it rather than leaving a page of refusals on screen. ## Limits and gotchas - The overview's trend window is fixed at 28 days and is not configurable. - "Hours logged" on the tile is the same trailing window, not the current month. - The console has no username segment, so a link to a console page is shareable between admins as-is. A link copied from a *workspace* page carries a handle and will be rewritten for whoever opens it. - If the overview fails to load it says so plainly rather than rendering zeros — a dashboard of zeros is indistinguishable from a company that has done nothing. ## Related - [Members](/docs/admin/members) — who is in the workspace, and how they get in. - [Roles and permissions](/docs/start/roles-and-permissions) — the four roles and what each starts with. - [Settings](/docs/admin/settings) — the country, the working week and the locale everything else reads. - [Workload](/docs/admin/workload) — capacity against committed and logged work. ## Related - [Members](https://projectri.com/docs/admin/members.md): The workspace roster and the pending invite list — invite people, change roles, suspend, remove, and do any of those to many people at once. - [Settings](https://projectri.com/docs/admin/settings.md): Branding, region, locale, the working week and storage policy — the tenant preferences that every other screen in Projectri reads. - [Permissions](https://projectri.com/docs/admin/permissions.md): The role-by-permission grid and the per-member override table — what each role may do in this workspace, and how one person differs from their role. - [Workload](https://projectri.com/docs/admin/workload.md): Who is carrying what and who has room — open tasks, overdue work and logged hours against each person's weekly capacity, with the capacity and skills editable in place. - [Roles and permissions](https://projectri.com/docs/start/roles-and-permissions.md): The four workspace roles, the permission keys behind them, and why two people in the same workspace see different screens.