Roles & permissions

Five roles shape navigation, workspace actions, and server-side authorization.

Role	Can do
`owner`	Full workspace, billing, governance deletion approval, API keys, integrations, audit, and operating-mode control.
`admin`	Customer-workspace administration, API keys, integrations, audit, document deletion, and operating-mode control. Billing remains owner-only, and shared reference-graph mutation remains platform-staff-only.
`growth_leader`	Company profile, pursuits, agents, capture approvals, task and capacity allocation, partner agreements and ecosystem governance, and advanced portfolio, reporting, and outcome modules when enabled by operating mode.
`bd_user`	Radar, forecast, intelligence, pipeline, capture generation, operations tasks, partner profiles, engagements and rooms, workspace notes, and workflow execution without approval, agreement governance, capacity allocation, or account administration.
`viewer`	Read-only intelligence, partner and relationship evidence, pipeline state, saved AI outputs, documents, artifacts, operations tasks/calendar/capacity, notes, and workflow history.

Operating modes

Owners and administrators can set a workspace to Solo, Small Business, Growth, or Enterprise. Every mode keeps the core Signal, Radar, Pipeline, Workbench, Operations, and Intelligence surfaces. Growth and Enterprise also expose Command Center, Portfolio Strategy, Reporting Center, and Outcomes to leadership roles.

The workspace manifest is resolved from tenant settings and role on every server render. Hidden direct routes return the user to their role home, while mutation routes independently enforce RBAC and return 403 when denied.

Audit Center reads and exports are restricted to Owner and Admin. A denied authenticated request records tenant-scoped security evidence with its request ID and source IP before returning 403.

Reporting Center reads, report definitions, schedules, exports, and shares are restricted to Owner, Admin, and Growth Leader. Shared report tokens expose one immutable snapshot and do not grant workspace access.

Independent staff applications

WinLayer Administration, internal Developer Operations, and Customer Service are standalone internal applications. They do not use Clerk, customer workspace membership, customer onboarding, or a subscription role. Each application has its own username, password hash, signed session cookie, login route, navigation, and API capability boundary.

Application	Independent access boundary
`/admin/login`	Admin credentials only. Grants the Admin cookie and cross-customer account, subscription, commercial, platform-health, graph identity-resolution/rebuild, and audit controls. It cannot enter Developer or Customer Service.
`/staff/developer/login`	Internal Developer Operations credentials only. Grants the Developer staff cookie for platform telemetry and diagnostics. It cannot enter Admin, Customer Service, or a customer's Clerk workspace.
`/customer-service/login`	Customer Service credentials only. Grants the Support cookie for cross-customer case triage and persisted case-state changes. It cannot enter Admin or Developer.
`/access`	Public staff-application gateway. It reports each application session independently and links to that application's own login; it does not authenticate anyone.

The customer-facing /developer portal is different: workspace Owners and Admins use their normal Clerk session to create tenant-scoped API keys and webhooks within the active subscription's operational limits. API credentials are included access controls, not separately purchased products. A customer API key never grants access to an internal staff application.

Staff sessions are HttpOnly, SameSite=Strict, HMAC signed, expire after eight hours, and are verified again by the API before role-specific route allowlists run. Purchasing a plan, owning a workspace, or signing in through Clerk can never grant staff access.

A missing application session returns 401; a valid staff role attempting another application's operation returns 403.