Administration
Roles
| Role | Can |
|---|---|
admin | Everything in the workspace, including users, billing, settings |
engineer | Create and edit all engineering data, approve changes |
reviewer | Review and approve, limited editing |
viewer | Read-only |
guest | Minimal read access |
supplier | Portal only — see supplier portal; never mixes with staff access |
Users & audit
- Admin → Users — invite teammates, change roles, deactivate accounts. Supplier logins are managed from each supplier's page instead and never appear here.
- Admin → Audit Log — every material action (creates, state changes, approvals, downloads, sign-ins) with actor, entity and timestamp.
Plans
| Plan | Seats | Storage | Changes/mo | Extras |
|---|---|---|---|---|
| community | 3 | 1 GB | 10 | — |
| pro | 25 | 100 GB | unlimited | advanced approval workflows, BOM CSV import |
| business | 100 | 1 TB | unlimited | + supplier portal logins, quality module (NCR, CAPA, FMEA, inspection plans) |
| enterprise | unlimited | unlimited | unlimited | same features, dedicated onboarding and support |
Limits are enforced server-side and fail closed. Supplier portal logins are free — they don't consume seats.
Workspace settings
Admin → Settings — rename the workspace, see the slug, plan and usage, and jump to billing.
Platform operations
Operators listed in the deployment's PLATFORM_ADMIN_EMAILS get an extra
Platform Admin console at /admin. It is cross-tenant and invisible to
everyone else. Sections:
| Section | What it shows | Actions |
|---|---|---|
| Overview | Visitors, sessions, page views, bounce rate, live visitors; accounts created, activated and paying workspaces, estimated MRR, active users; traffic trend, acquisition funnel, plan mix, workspace health | Date range and "include my own traffic" filters scope every number |
| Funnel | Visitor → viewed pricing → opened sign-up → created account → activated (first item, document or change) → paying, with step conversion; sources and campaigns that convert; recent sign-ups; weekly retention cohorts | |
| Traffic | Top pages, entry pages, sources, countries, devices, browsers, operating systems, languages; live panel; active users over time | |
| Tenants | Every workspace with plan, status, health (active / new / cooling / dormant), users, records, storage, last activity | Change plan, suspend / reactivate, delete, jump to members |
| Users | Every user across workspaces with role, status, last login; counts by status, role and recency; search, filters, keyboard navigation, CSV export | Open a user: change role or status (deactivation signs them out), mint a one-time password reset link, sign out everywhere, delete |
| Events | Raw analytics event feed with filters; click a row for that visitor's journey grouped by session | |
| Audit log | Cross-tenant audit trail; every operator action is recorded as platform_* | |
| System health | Database and object-storage size, API uptime and memory, active sessions, record counts, live visitors |
How the analytics are collected
The web app includes a small first-party tracker (src/lib/analytics.ts) that
posts page views and funnel events to POST /api/t on the same origin. There is
no third-party script and no cookie: the visitor id is a random value in
localStorage (session-only when the browser sends Do Not Track), the IP
address is hashed before storage, and country is resolved on the server at
country level only. Crawlers and monitoring agents are dropped by user agent.
Signed-in users' events carry their user and workspace so the funnel can link a
visitor to the account they created.
Operator traffic is tagged as internal, both by login and by a sticky flag on the operator's browser, and is excluded from every number unless the "include my own traffic" switch is on. Workspaces that contain an operator login are excluded the same way.
Account figures (accounts created, activated, paying, MRR) always come from the database, never from the tracker, so they stay correct even for visitors who block scripts.
Guard rails on user management
- Operators cannot change or delete their own account from the console.
- A workspace is never left without an active admin: demoting, deactivating or deleting the last active admin is refused.
- The only user of a workspace cannot be deleted; delete the workspace instead.
- Users who authored items, changes or quality records cannot be deleted (history keeps its author); deactivate them, which also revokes their sessions.
- Supplier portal logins cannot change role and are reset by their buyer.