Workspaces

A workspace represents an organization, company, team, or client inside SaaSStinger Lite.

Every piece of business data belongs to a workspace. Projects, members, invitations, notifications, audit logs, and usage records are all isolated within a workspace.

This architecture enables SaaSStinger Lite to support secure multi-tenant applications while keeping the codebase simple and scalable.

What You'll Learn

In this guide you'll learn:

• What a workspace is
• How workspaces are created
• How data isolation works
• How users join workspaces
• How workspace switching works
• Best practices for extending the workspace model

Why Workspaces?

Without workspaces, every authenticated user would share the same data.

Imagine two companies using your application.

Acme Ltd
Projects
Members
Tasks

---------------------

Globex Inc.
Projects
Members
Tasks

Their information must never overlap.

Workspaces solve this problem by creating an isolated environment for each organization.

Workspace Architecture

Every workspace owns its own resources.

Workspace
    │
    ├────────── Members
    ├────────── Projects
    ├────────── Invitations
    ├────────── Notifications
    ├────────── Usage
    └────────── Audit Logs

Every query throughout the application is scoped to the active workspace.

Architecture Note

SaaSStinger Lite is designed as a multi-tenant application.

Instead of creating separate databases for each customer, all tenants share the same Firestore database while Firestore Security Rules ensure each workspace can only access its own data.

Creating a Workspace

Every new user completes onboarding before accessing the dashboard.

The workspace creation form requires only one field:

• Workspace Name

After submission, SaaSStinger Lite automatically creates:

• A workspace document
• An OWNER membership for the creator
• Usage tracking document
• Updates the user's activeWorkspaceId

The user is then redirected to the dashboard.

Workspace Document

A workspace document contains the core information about an organization.

Typical fields include:

{
  id: string
  name: string
  createdAt: Timestamp
  updatedAt: Timestamp
}

Additional metadata can be added as your application grows.

Active Workspace

A user can belong to multiple workspaces.

Only one workspace is active at a time.

The currently selected workspace is stored in the user's profile:

activeWorkspaceId

Whenever the user switches workspaces:

1. The profile is updated.
2. The dashboard refreshes.
3. Future queries use the new workspace.
4. Firestore requests are scoped to the selected workspace.

This provides a seamless experience while maintaining data isolation.

Memberships

Workspaces do not store a list of users directly.

Instead, SaaSStinger Lite uses a dedicated memberships collection.

User
   │
Membership
   │
Workspace

This allows:

• One user → many workspaces
• One workspace → many users

It also simplifies role management and invitations.

Data Isolation

Every feature respects the active workspace.

Examples include:

• Projects
• Tasks
• Notes
• Tables
• Notifications
• Audit Logs
• Usage
• Members

A user cannot access resources belonging to another workspace.

This isolation is enforced through:

• Workspace-aware queries
• Server-side authorization
• Firebase Admin SDK verification
• Firestore Security Rules

Security Note

Never trust a workspace ID received from the browser. Always verify that the authenticated user belongs to the requested workspace before performing privileged operations.

Workspace Switching

Switching workspaces updates the user's active workspace and reloads the application context.

Typical flow:

Select Workspace
        │
        ▼
Update activeWorkspaceId
        │
        ▼
Refresh Workspace Context
        │
        ▼
Reload Dashboard Data

Because every query references the active workspace, users immediately see the correct data after switching.

Adding Additional Workspaces

After onboarding, users can create additional workspaces from the dashboard (subject to your application's plan limits).

Each new workspace follows the same initialization process:

• Workspace document created
• Creator assigned OWNER role
• Usage tracking initialized

Extending Workspaces

As your application evolves, you may choose to store additional workspace-level settings such as:

• Company logo
• Brand colors
• Business address
• Default timezone
• Billing information
• Feature flags

Keep organization-specific data in the workspace document rather than the user profile.

Best Practices

• Scope every query to the active workspace.
• Keep workspace documents lightweight.
• Store user information in profiles, not workspaces.
• Use memberships to manage access.
• Verify workspace membership on every privileged request.

Common Mistakes

Storing Members Inside the Workspace Document

Avoid embedding member lists in workspace documents.

Use the dedicated memberships collection instead.

Trusting Client-Supplied Workspace IDs

Always validate that the authenticated user belongs to the requested workspace before reading or modifying data.

Mixing Personal and Organization Data

User preferences belong in the profile.

Organization settings belong in the workspace.

Related Articles

• User Profiles
• Members
• Invitations
• RBAC & Permissions
• Usage Tracking

Next Steps

Now that you understand how organizations are isolated, continue with Members to learn how users are associated with workspaces and how collaboration is managed.