Skip to main content
DelightBridge is built for teams. Multiple users can access the same workspace, collaborate on customer emails, and maintain consistent support quality with role-based access control.

​
Permission System

DelightBridge uses a hierarchical permission system with four levels.

​
Permission Levels

Read-only access to the workspace:✅ Can:
  • View all threads and conversations
  • Read email content and message threads
  • See AI-generated drafts
  • View categories and tags
  • Search and filter threads
❌ Cannot:
  • Edit drafts or replies
  • Send emails
  • Change service settings
  • Manage team members
Use Case: Junior team members, observers, trainees

​
Permission Hierarchy

Permissions are cumulative. Higher levels inherit all capabilities from lower levels: 
View → Edit → Send → Admin
  0      1      2      3
Implementation: types.ts:26-35
The system checks permissions using hasPermission() utility which compares permission ranks. For example, Admin (rank 3) can perform all actions that require Send (rank 2) or below.

​
Workspace Members

Manage your team members in the Permissions tab of the Settings modal.

​
Adding Team Members

1

Open Permissions Tab

Settings → “권한 관리” (Permissions Management)
2

Enter Email

Type the new member’s email address in the input field.
3

Choose Permission Level

Select the initial permission level from the dropdown (View, Edit, Send, or Admin).
4

Add Member

Click “멤버 추가” (Add Member). The member is added to the workspace immediately.
5

Member Onboarding

The new member can now:
  • Sign in with their Google account (must match the email)
  • Access the workspace according to their permission level
  • View threads from all connected services
Members are added to the workspace, not individual services. All members can see threads from all services, but permissions apply globally.

​
Viewing Team Members

The Permissions tab shows all workspace members with:
ColumnDescription
AvatarFirst initial of member’s name
NameFull name from Google account
EmailEmail address (sign-in identifier)
Login Status”아직 로그인 안함” (Not yet logged in) if they haven’t accessed the workspace
PermissionCurrent permission level with color coding
ActionsChange permission or remove member

​
Changing Permissions

1

Locate Member

Find the member in the Permissions tab list.
2

Open Permission Dropdown

Click the colored permission badge (e.g., “View”, “Send”).
3

Select New Permission

Choose the desired permission level from the dropdown menu.
4

Immediate Effect

The change takes effect immediately. The member’s access level updates on their next action or page refresh.
Changing someone’s permission to View or Edit will prevent them from sending emails. Make sure you communicate permission changes to your team.

​
Removing Members

  1. Click the trash icon next to the member’s name
  2. Confirm the removal
  3. The member loses access immediately
  4. Their email is removed from the workspace member list
API endpoint: src/app/api/members/[email]/route.ts

​
Admin Configuration

Certain actions in DelightBridge require Admin permission.

​
Admin-Only Features

Connect Gmail

Only Admins can connect new Gmail accounts to services via OAuth.Error message for non-Admins: “Google 계정 연결은 Admin 권한이 필요합니다.”

Service Management

Create, edit, and delete services. Non-Admins can view but not modify service settings.

Documents & Signatures

Edit reference documents and email signatures. Other users see read-only views.

Category Management

Create, edit, and delete categories. Non-Admins use existing categories but cannot change them.

​
Environment-Based Admins

You can designate permanent Admins via environment variable: 
# .env.local
ADMIN_EMAILS="[email protected],[email protected]"
Environment-based Admins:
  • Always have Admin permission (cannot be changed via UI)
  • Identified by isAdminByEnv: true flag
  • Cannot be removed from the workspace
  • Useful for system administrators and founders
Implementation: src/lib/admin-emails.ts
Use environment-based Admins to ensure at least one person always has full access, even if permissions are accidentally changed in the database.

​
Collaboration Workflows

Here are common team workflows enabled by DelightBridge’s permission system.

​
Two-Tier Review Process

1

Agent Drafts Response

Team member with Edit permission:
  • Reviews incoming thread
  • Reads AI-generated draft
  • Uses Talk to Draft to refine
  • Formats the message appropriately
  • Leaves thread in “inbox” status
2

Supervisor Reviews

Team member with Send permission:
  • Filters for threads with drafts ready
  • Reviews draft quality
  • Makes final edits if needed
  • Sends the email
  • Thread moves to “sent” status
Why this works:
  • Junior agents can practice writing responses without risk
  • Supervisors maintain quality control
  • AI speeds up initial drafting
  • Clear separation of responsibilities

​
Bulk Send Workflow

1

Agents Prepare Drafts

Multiple team members with Edit permission work in parallel:
  • Each takes threads from inbox
  • Reviews and refines drafts
  • Leaves threads unchecked
2

Supervisor Bulk Send

Team member with Send permission:
  • Reviews threads with completed drafts
  • Uses checkboxes to select multiple threads
  • Clicks “Send all” in the bulk action bar
  • All selected emails are sent at once
Benefits:
  • Efficient for high-volume support
  • Reduces context switching
  • Maintains quality with review step

​
Distributed Support Team

1

Shared Inbox

All team members have Send permission and work from the same inbox:
  • Agents claim threads by opening them
  • Real-time unread status prevents duplicates
  • Each agent handles threads independently
2

Admin Oversight

Admin monitors and adjusts:
  • Reviews sent threads for quality
  • Updates reference documents based on patterns
  • Adjusts categories as needed
  • Manages team permissions
Ideal for:
  • Small teams with flat structure
  • Experienced support agents
  • Fast-paced environments

​
User Interface Behavior

The UI adapts based on your permission level.

​
Permission-Based UI Elements

UI shows:
  • ✅ Sidebar with services (no settings icon)
  • ✅ Mail list (read-only)
  • ✅ Thread view (read-only)
  • ✅ Draft content (read-only, no editor)
  • ❌ Draft editor toolbar
  • ❌ Send button
  • ❌ Talk to Draft panel
  • ❌ Settings modal

​
Permission Check Implementation

Every API route validates permissions server-side: 
// Example from src/lib/session.ts
export async function requireSession() {
  const session = await auth();
  if (!session?.user?.email) {
    return { 
      session: null, 
      unauthorized: NextResponse.json(
        { error: 'Unauthorized' }, 
        { status: 401 }
      )
    };
  }
  return { session, unauthorized: null };
}
Additional checks for specific permissions happen in individual route handlers.
UI elements are hidden for non-permitted actions, but the backend always enforces permissions. Never rely solely on frontend checks.

​
Current User Display

Your current user information appears in the settings sidebar.

​
User Info Card

Shows:
  • Profile Picture: From Google account (or initials if no picture)
  • Name: Full name from Google profile
  • Email: Sign-in email address
  • Permission Level: Current permission badge
This helps you:
  • Confirm you’re logged in with the correct account
  • Know your current permission level
  • Identify yourself in multi-user sessions
Implementation: SettingsModal.tsx:180-208

​
Best Practices

Grant the minimum permission needed for each role:
  • New hires: Start with View for training period
  • Junior agents: Use Edit with supervisor review
  • Experienced agents: Grant Send for independence
  • Team leads: Provide Admin for full control
You can always increase permissions as team members gain experience.
Create internal documentation for your team:
  • Who has which permission level and why
  • Expected workflow (e.g., “Agents draft, supervisors send”)
  • How to request permission changes
  • Escalation procedures for special cases
Review team permissions quarterly:
  • Remove members who have left the team
  • Adjust permissions based on role changes
  • Verify environment-based Admins are still appropriate
  • Check for orphaned or unused accounts
Don’t rely on a single Admin:
  • Designate at least 2-3 Admins
  • Include at least one environment-based Admin
  • Ensure Admins are in different time zones (for 24/7 teams)
  • Document how to access admin controls
Make sure team members understand:
  • What they can and cannot do at their permission level
  • How to request assistance from higher permission users
  • Why certain actions require Admin approval (security, consistency)
  • What happens if they try unauthorized actions (error messages, not account suspension)

​
Authentication Flow

DelightBridge uses NextAuth.js with Google OAuth for authentication.

​
Sign-In Process

1

Navigate to Login

Visit /login or get redirected if not authenticated.
2

Sign In with Google

Click “Sign in with Google” button.
3

Google Authorization

Authorize DelightBridge to access your Google profile (name, email, picture).
4

User Creation or Lookup

Backend:
  • Checks if user exists in workspace_members table
  • If not found, denies access (must be added by Admin first)
  • If found, creates or updates user in users table
  • Loads permission level from workspace_members
5

Session Creation

NextAuth creates a session cookie with:
  • User ID
  • Email
  • Name
  • Picture URL
  • Permission level
6

Redirect to App

User is redirected to main app (/) with full access according to their permission.
Auth configuration: auth.config.ts and auth.ts

​
Session Management

Sessions persist across page refreshes:
  • Session Duration: 30 days by default
  • Storage: Encrypted session cookie
  • Logout: Click logout in sidebar → redirects to /login
Implementation: src/lib/session.ts

​
Troubleshooting

Symptoms: User sees “Unauthorized” or is redirected to login repeatedly.Causes & Solutions:
  1. Not added to workspace
    • Admin must add their email in Settings → Permissions first
    • Email must exactly match their Google account
  2. Wrong Google account
    • User must sign in with the exact email added to workspace
    • Check for typos or aliases
  3. Permission set to invalid value
    • Verify their permission in database is one of: view, edit, send, admin
Symptoms: Send button is grayed out or missing.Causes & Solutions:
  1. Insufficient permission
    • User needs Send or Admin permission
    • Admin can change permission in Settings → Permissions
  2. Draft not ready
    • Draft must be generated or manually entered
    • Check that draft content is not empty
  3. Thread already sent
    • Threads with status “sent” cannot be sent again
Symptoms: Settings icon is not visible in sidebar.Cause: User does not have Admin permission.Solution: Admin must change user’s permission to Admin in Settings → Permissions.
Symptoms: User A makes changes but User B doesn’t see them.Causes & Solutions:
  1. Stale data
    • User B needs to refresh the page
    • DelightBridge doesn’t use real-time sync (no WebSockets)
  2. Cache issue
    • Hard refresh (Ctrl+Shift+R or Cmd+Shift+R)
    • Clear browser cache
  3. Sync lag
    • Run manual incremental sync in Settings → Services

Service Management

Learn how Admins configure services and settings

Email Management

Understand the inbox and thread workflows team members use

Build docs developers (and LLMs) love

Get started for freeTalk to us