DashboardSupportWelcome

👤 USER DOCS

Getting Started

Daily Operations

Shift Workspace & TasksPre-Shift SetupLine-Up CardsShift ReportsForms

Staff & Locations

Staff SchedulingManaging Locations

Oversight

Manager ReportsAnalyticsPre-Shift & Compliance

Incidents & Feedback

Incident ReportingAnonymous FeedbackMessages & Announcements

AI & Settings

AI ChatgearApp Settings

Administration

Dashboard & OnboardingAdmin

⚙️ DEVELOPER DOCS

Getting Started

Getting StartedDevelopmentDeployment Guide

Architecture

Architecture OverviewData FlowArchitecture Decision Records

Core Domain

Core DomainDatabase ReferenceLocations DomainAuth & RBACScheduling DomainReports DomainIncidents DomainNotifications DomainAudit Log & OptimizationDesign Audit Findings

Frontend

Frontend ArchitectureFormsLoading SkeletonsComponentsPWA & NotificationsimageScreenshots

API Reference

API Reference

Endpoints

POS Sales APIOptimization Data APISchedule Shifts APIEmployee Export APIReports APIIncidents APIAI Chat APIPush Notifications APIWebhooks APICron API

Contributing

ContributingcodeCode Examples

Security

Security & Compliance
Danvas IconDanvas
Danvas IconDanvas

Auth & RBAC

Technical design of Clerk integration and Role-Based Access Control

Overview

Danvas uses Clerk for authentication and identity management. Multi-tenancy is implemented using Clerk Organizations, where each organization represents a Team in our database.

Clerk Integration

User Provisioning

When a user signs in for the first time, our middleware calls provisionUser() in @repo/auth.

  1. Webhook Sync: Clerk webhooks (user.created, user.updated) sync user data to our users table.
  2. Metadata: Role and Location assignments are stored in Clerk publicMetadata to enable efficient client-side checks and guard against unauthorized access at the edge.
  3. Setup Flow: /onboarding collects optional profile details like phone and job roles, then marks users.onboardingComplete in the local database. Profile setup is separate from team assignment.

Middleware

The @repo/auth package provides middleware that handles:

  • Session validation.
  • Redirecting unauthenticated users to sign-in.
  • Ensuring users belong to an active team.
  • Resolving the teamId from the active organization.

Role-Based Access Control (RBAC)

We support three primary roles, stored in the users table and Clerk metadata.

RolePermissions
adminFull access to all team locations, billing, and settings.
managerAccess to specific locations, reports, and scheduling.
memberEnd-user access (staff) to filing reports and viewing schedules.

Auth Guards

Use these helpers in Server Components and Actions to enforce security:

Locations Domain

Technical design of multi-location hierarchy and data isolation

Scheduling Domain

Technical architecture of the management scheduling system

On this page

OverviewClerk IntegrationUser ProvisioningMiddlewareRole-Based Access Control (RBAC)Auth GuardsSession DataRelated
// apps/app/src/app/(authenticated)/admin/actions.ts
import { requireAdmin } from "@repo/auth/get-user-auth";

export async function adminAction() {
  const auth = await requireAdmin(); // Throws if not admin
  // ...
}

Session Data

The get-user-auth.ts helper returns a session object containing:

  • userId: The Clerk ID.
  • teamId: The active Organization ID.
  • role: The user's role in the organization.
  • locationIds: The array of authorized locations.

Related

Database Schema

Locations Domain

Frontend Architecture