Accounts, sessions, roles, and billing: what the server enforces
Users and sessions
When you sign up or log in, the app uses Better Auth with email and password (and organization support). The server sets a secure, HTTP-only session cookie in the browser. On each request, the Worker reads that cookie, loads your user record, and knows who you are — without putting passwords into every link.
Organizations and “active org”
Most users belong to one organization (your company’s workspace). Your account links to an organization member row that includes your role. The session also tracks which organization is active when you have more than one context (the common case is a single org). Server code loads subscription and settings for that active organization so billing and custom field labels line up with what you see on screen.
Roles: who can invite, who can clear violations, who can pay
Roles such as administrator, management, inspector, and staff are not just labels — they gate actions. For example, clearing certain violation workflows or managing invitations may be limited to roles your deployment defines. Billing screens are typically restricted to administrators (or equivalent) so payment methods are not exposed to every viewer on the floor.
Subscription and trial state
The app stores a subscription row per organization with status (trialing, active, incomplete, and so on). If the subscription is missing or not in good standing, the server may redirect administrators to billing while still allowing other roles to use core safety features where policy allows — exact rules are implemented in the layout load for the authenticated app. That is why two people in the same company can sometimes see different menus: their roles and the org’s billing state differ.
Invitations
New teammates receive an invitation tied to an email and a role. Until they accept, they are not members. After acceptance, their user ID joins the organization with the assigned role, and the same session and org-scoping rules apply to them.
Putting it together
Every “can I do this?” question on the server is answered by combining: Are you signed in? Which organization? What is your role? Is the subscription valid for admin-only billing flows? Data access then adds: Does this row’s organization ID match yours? That layered check is how the product stays multi-tenant without mixing customer data.