Skip to main content

​
Overview

Workspaces are the foundation of EventPalour’s multi-tenancy architecture. Each workspace represents an isolated environment where organizations can manage their events, team members, and event-related resources.
Think of a workspace as your organization’s dedicated event management hub. All events, tickets, and team collaboration happen within the context of a workspace.

​
Data Model

​
Workspace Schema

The workspace table contains the following key fields:
FieldTypeDescription
idvarchar(16)Unique workspace identifier (auto-generated)
namevarchar(255)Display name of the workspace
descriptiontextOptional workspace description
image_urltextWorkspace logo/avatar URL
invite_codetextUnique code for inviting members (unique, indexed)
user_idvarchar(16)Owner’s user ID (foreign key to user table)
websitevarchar(255)Organization website
phonevarchar(50)Contact phone number
social_xvarchar(255)X (Twitter) profile URL
social_facebookvarchar(255)Facebook profile URL
social_linkedinvarchar(255)LinkedIn profile URL
social_instagramvarchar(255)Instagram profile URL
social_githubvarchar(255)GitHub profile URL
created_attimestampWorkspace creation timestamp
updated_attimestampLast update timestamp

​
Workspace Members

Members are managed through the workspace_members table: 
{
  id: varchar(16),              // Member record ID
  user_id: varchar(16),         // Reference to user
  workspace_id: varchar(16),    // Reference to workspace
  role: workspace_role_enum     // Member's role (default: "member")
}

​
Workspace Roles

Each workspace member has one of three roles:

Admin

Full workspace access including member management, settings, and all event operations.

Moderator

Can manage events and content but cannot modify workspace settings or manage members.

Member

Basic access to view events and participate in workspace activities.
Roles are defined in /lib/db/schema/enums.ts as:
enum WorkspaceRole {
  ADMIN = "admin",
  MODERATOR = "moderator",
  MEMBER = "member"
}

​
Workspace Relationships

A workspace is connected to multiple entities:

​
Workspace Invitations

Workspaces can invite new members via the workspace_invitations table:
FieldTypeDescription
idvarchar(16)Invitation ID
workspace_idvarchar(16)Target workspace
emailvarchar(255)Invitee’s email address
roleworkspace_role_enumRole to assign (default: “member”)
invited_byvarchar(16)User who sent the invitation
tokenvarchar(64)Unique invitation token
acceptedbooleanAcceptance status (default: false)
expires_attimestampExpiration timestamp
Invitation tokens are single-use and expire after a set period. The system tracks both workspace ID and email in a composite index for efficient lookups.

​
Multi-Tenancy Architecture

EventPalour uses workspace-based multi-tenancy where:
  1. Data Isolation: All events, categories, and ticket types are scoped to a workspace
  2. Team Collaboration: Multiple users can be members of the same workspace
  3. Resource Ownership: Each workspace has a single owner (creator) but can have multiple admins
  4. Invite-based Access: Users join workspaces through unique invite codes or email invitations

​
Common Use Cases

​
Creating a Workspace

When a user signs up as an organizer, they’re prompted to create their first workspace: 
const workspace = {
  name: "Tech Conference Co",
  description: "Annual technology conferences",
  user_id: currentUser.id,
  invite_code: generateUniqueCode(),
  image_url: uploadedLogoUrl
};

​
Inviting Team Members

1

Send Invitation

Admin creates an invitation with the target email and desired role.
2

Email Notification

System sends invitation email with unique token link.
3

Accept Invitation

Recipient clicks link and accepts the invitation.
4

Join Workspace

System creates workspace_members record with specified role.

​
Managing Multiple Workspaces

Users can be members of multiple workspaces with different roles:
  • Owner of “Tech Conference Co” (as creator)
  • Admin in “DevOps Meetup Group”
  • Member in “Community Events Hub”

​
Best Practices

Use clear, descriptive names that reflect your organization or event series. Names are displayed throughout the platform and in public event pages.
Treat invite codes as sensitive. They provide direct access to your workspace. Rotate codes if they’re accidentally exposed.
Follow the principle of least privilege. Start members with the “member” role and promote to “moderator” or “admin” as needed.

​
Technical Details

​
Schema Location

/lib/db/schema/workspace.ts

​
Database Constraints

  • invite_code has a unique constraint and index for fast lookups
  • user_id cascades on delete (deleting owner deletes workspace)
  • All member and invitation relationships cascade on workspace deletion

​
Automatic Fields

  • id is auto-generated using nano ID (16 characters)
  • created_at defaults to current timestamp
  • updated_at automatically updates on record modification

Build docs developers (and LLMs) love

Get started for freeTalk to us