Skip to main content
DelightBridge implements a hierarchical permission system with four levels: View, Edit, Send, and Admin. This guide explains what each level can do and how to manage workspace members.

​
Permission Levels

Permissions are defined as an enum in the database schema and enforce a clear hierarchy: 
export const permissionEnum = pgEnum('permission_level', [
  'view',
  'edit', 
  'send',
  'admin'
]);

​
Permission Hierarchy

The hierarchy follows this order (from lowest to highest): 
view < edit < send < admin
Higher permission levels inherit all capabilities of lower levels. The permission check function from types.ts:33 enforces this: 
const PERMISSION_RANK: Record<PermissionLevel, number> = {
  view: 0,
  edit: 1,
  send: 2,
  admin: 3,
};

export function hasPermission(
  userLevel: PermissionLevel, 
  required: PermissionLevel
): boolean {
  return PERMISSION_RANK[userLevel] >= PERMISSION_RANK[required];
}

​
View Permission

What View users can do:
  • Read email threads and messages
  • View service configurations
  • See categories and workspace members
  • Browse all sections of the interface
What View users cannot do:
  • Edit drafts or thread properties
  • Generate AI drafts
  • Send emails
  • Modify service settings
  • Manage workspace members
View permission is ideal for stakeholders who need visibility into customer communications without the ability to respond.

​
Edit Permission

What Edit users can do:
  • Everything View users can do
  • Edit draft content
  • Use “Talk to Draft” to refine drafts with AI
  • Translate drafts
  • Change thread categories
  • Mark threads as read/unread
  • Archive threads
What Edit users cannot do:
  • Send emails (drafts remain unsent)
  • Generate new AI drafts from scratch
  • Modify service settings
  • Manage workspace members
Edit permission is perfect for team members who prepare responses but require approval before sending.

​
Send Permission

What Send users can do:
  • Everything Edit users can do
  • Generate AI drafts
  • Send emails to customers
  • Bulk send multiple drafts
What Send users cannot do:
  • Create or modify services
  • Connect Gmail accounts
  • Manage workspace members
  • Change service documents or signatures
Send permission is for frontline support agents who handle customer communications end-to-end.

​
Admin Permission

What Admin users can do:
  • Everything Send users can do
  • Create and configure services
  • Connect Gmail accounts via OAuth
  • Manage service documents and signatures
  • Create and edit categories
  • Add, modify, and remove workspace members
  • Trigger manual syncs
  • Access all API endpoints
Admin permission provides complete control over DelightBridge. Only grant it to trusted team leads and administrators.

​
Managing Workspace Members

Workspace members are users who have access to DelightBridge but aren’t configured as admin emails.

​
Adding Members

Admins can add members through the Settings modal or the API: 
POST /api/members
Content-Type: application/json

{
  "email": "[email protected]",
  "permission": "edit"
}
The member is added to the workspace_members table: 
const [member] = await db
  .insert(workspaceMembers)
  .values({
    email: normalizedEmail,
    permission: nextPermission,
  })
  .onConflictDoUpdate({
    target: workspaceMembers.email,
    set: { permission: nextPermission },
  })
  .returning();
1

Open Settings

Click Settings in the sidebar (admin only).
2

Navigate to Members Tab

Switch to the Members tab to view current workspace members.
3

Add New Member

Enter the member’s email address and select their permission level.
4

Save Changes

Click Add Member. They can now log in with their Google account.

​
Updating Member Permissions

To change a member’s permission level: 
PATCH /api/members/{email}
Content-Type: application/json

{
  "permission": "send"
}
Or use the Settings modal:
  1. Find the member in the list
  2. Select a new permission level from the dropdown
  3. Changes apply immediately
Permission changes take effect on the user’s next request. They may need to refresh their browser to see updated capabilities.

​
Removing Members

To revoke access: 
DELETE /api/members/{email}
This removes the member from workspace_members. They will be unable to log in on their next attempt.
Removing a member does not log them out immediately. They retain access until their session expires (typically 30 days).

​
Admin Emails vs Workspace Members

DelightBridge supports two types of admins:

​
Admin Emails (Environment-based)

Configured in .env.local: 
ADMIN_EMAILS=[email protected],[email protected]
Characteristics:
  • Hardcoded access that cannot be revoked through the UI
  • Always have admin permission, even if added to workspace_members with a lower level
  • Automatically upgraded to admin during login
  • Cannot be removed from the members list in the UI

​
Workspace Member Admins

Added through the members management interface with admin permission: Characteristics:
  • Can be promoted to admin by existing admins
  • Permission can be changed or revoked
  • Appear in the members list
  • Have identical capabilities to environment-based admins
Use Admin Emails for:
  • Permanent administrators
  • System owners
  • Users who should never lose access
Use Workspace Member Admins for:
  • Temporary administrators
  • Team leads whose role may change
  • Users whose access might need to be revoked

​
Permission Enforcement

Permissions are enforced at multiple levels:

​
API Route Protection

API routes check permissions before processing requests: 
import { requirePermission } from '@/lib/session';

export async function POST(req: NextRequest) {
  const { session, unauthorized, forbidden } = 
    await requirePermission(['admin', 'send']);
  
  if (unauthorized) return unauthorized; // 401
  if (forbidden) return forbidden;       // 403
  
  // Process request
}
From session.ts:33: 
export async function requirePermission(allowed: PermissionLevel[]) {
  const { session, unauthorized } = await requireSession();
  if (unauthorized || !session) {
    return { session: null, unauthorized, forbidden: null };
  }

  const permission = getSessionPermission(session);
  if (!permission || !allowed.includes(permission)) {
    return {
      session,
      unauthorized: null,
      forbidden: NextResponse.json({ error: 'Forbidden' }, { status: 403 }),
    };
  }

  return { session, unauthorized: null, forbidden: null };
}

​
Frontend UI Restrictions

The UI conditionally renders features based on permissions: 
// Example from MainLayout.tsx
const canSend = hasPermission(userPermission, 'send');
const canEdit = hasPermission(userPermission, 'edit');
const canAdmin = hasPermission(userPermission, 'admin');

{canAdmin && (
  <button onClick={openSettings}>Settings</button>
)}

{canSend && (
  <button onClick={sendEmail}>Send</button>
)}
Frontend restrictions are for UX only. All authorization is enforced on the backend to prevent bypassing through browser tools.

​
Permission-Specific API Endpoints

​
Admin-Only Endpoints

  • POST /api/services - Create service
  • PATCH /api/services/{id} - Update service
  • DELETE /api/services/{id} - Delete service
  • POST /api/services/{id}/connect - Connect Gmail
  • POST /api/services/{id}/sync - Trigger sync
  • GET /api/members - List members
  • POST /api/members - Add member
  • PATCH /api/members/{email} - Update member
  • DELETE /api/members/{email} - Remove member

​
Send-Level Endpoints

  • POST /api/threads/{id}/send - Send email
  • POST /api/draft/generate - Generate AI draft

​
Edit-Level Endpoints

  • PATCH /api/threads/{id} - Update thread (category, status, isRead)
  • PATCH /api/drafts/{threadId} - Update draft content
  • POST /api/draft/talk - Talk to Draft
  • POST /api/draft/translate - Translate draft

​
View-Level Endpoints

  • GET /api/threads - List threads
  • GET /api/threads/{id} - Get thread details
  • GET /api/services - List services
  • GET /api/drafts/{threadId} - Get draft

​
Best Practices

Grant the lowest permission level needed for each user’s role. You can always promote them later if needed.
Even for admins, prefer workspace member admins over environment-based admin emails unless the access should be permanent.
Periodically review workspace members to ensure permissions are still appropriate and remove users who no longer need access.
Keep a record of why specific users have certain permission levels, especially for send and admin permissions.
When developing new features, test with view and edit permissions to ensure proper enforcement.

​
Troubleshooting

Only admin users see the Settings button. Check their permission level in the members list.
Verify:
  1. The Gmail service is connected
  2. The thread has a draft ready
  3. No API errors in browser console
  4. User session is valid (try refreshing)
This is a display issue. Environment-based admins always have admin permission regardless of what’s shown. The session callback enforces this.
If the member is also in ADMIN_EMAILS, they cannot be removed through the UI. Remove them from the environment variable instead.

Build docs developers (and LLMs) love

Get started for freeTalk to us