Notifications

Notifications keep users informed about important events across their workspaces.

Rather than requiring users to manually check for updates, SaaSStinger Lite stores notifications in Firestore and presents them directly within the application.

Notifications are user-specific while remaining associated with a workspace, allowing each user to have their own notification history across multiple organizations.

What You'll Learn

In this guide you'll learn:

• How notifications work
• Where notifications are stored
• How notifications relate to workspaces
• Read and unread status
• Notification lifecycle
• Best practices for extending the system

Why Notifications?

A collaborative application generates many important events.

Examples include:

• Invitations
• Members joining
• Workspace updates
• Project activity
• Administrative actions

Without notifications, users would have to manually discover these changes.

Notifications provide timely visibility into workspace activity while maintaining a complete history.

Notification Architecture

Each notification belongs to:

• A single authenticated user
• A single workspace

Workspace
      │
      ▼
Notification
      │
      ▼
User

This means:

• Different users receive different notifications.
• Multiple workspaces maintain separate notification histories.
• Users can belong to multiple workspaces without mixing activity.

Architecture Note

Notifications are stored as individual Firestore documents rather than being generated dynamically.

This provides consistent history, supports read/unread status, and avoids recalculating events every time a page loads.

Notification Document

A notification typically contains information such as:

{
  id: string
  workspaceId: string
  userId: string
  title: string
  message: string
  type: string
  read: boolean
  createdAt: Timestamp
}

The exact schema may evolve as additional notification types are introduced.

Notification Types

SaaSStinger Lite supports notifications for workspace-related activity.

Examples include:

• Invitation events
• Membership events
• Workspace updates
• Project events
• Other collaboration activity

As your application grows, additional notification types can be introduced without changing the overall architecture.

Creating Notifications

Notifications are created automatically when important events occur.

Typical flow:

Workspace Event
       │
       ▼
Business Logic
       │
       ▼
Notification Created
       │
       ▼
Stored in Firestore
       │
       ▼
Visible to User

Developers do not need to manually manage notification creation throughout the UI.

Read and Unread Status

Every notification maintains its own read status.

New Notification
       │
       ▼
Unread
       │
User Opens
       │
       ▼
Marked as Read

Unread notifications help users quickly identify recent activity.

Reading a notification does not delete it.

Notification History

Notifications are retained after they have been read.

This allows users to review previous workspace activity whenever necessary.

Retaining notification history also provides useful context for collaboration without relying solely on audit logs.

Future versions of the application may introduce automatic cleanup or archival policies.

User-Specific Notifications

Although notifications are associated with a workspace, they are delivered to individual users.

For example:

Workspace A

 ├── Alice
 │     ├── Notifications
 │
 ├── Bob
 │     ├── Notifications
 │
 └── Carol
       ├── Notifications

Each user has their own notification feed.

This avoids exposing irrelevant or private activity to other members.

Relationship to Audit Logs

Notifications and audit logs serve different purposes.

Notifications help users stay informed.

Audit logs help administrators understand what happened.

Extending Notifications

As your application evolves, you may introduce additional notification categories such as:

• Task assignments
• Due date reminders
• Comments
• File uploads
• Billing events
• Security alerts

The existing architecture supports new notification types without requiring major structural changes.

Best Practice

Keep notification creation inside server-side business logic rather than client components. This ensures notifications are created consistently regardless of how an action is triggered.

Common Mistakes

Generating Notifications Dynamically

Dynamic notifications cannot easily support read/unread status or historical records.

Persist notifications in Firestore instead.

Sharing Notifications Between Users

Notifications should belong to individual users.

Avoid using a single shared notification feed for an entire workspace.

Deleting Notifications After Reading

Reading a notification should change its status—not remove it.

Retaining notifications provides valuable historical context.

Best Practices

• Store notifications as Firestore documents.
• Associate every notification with both a user and a workspace.
• Support read and unread states.
• Generate notifications from trusted server-side logic.
• Retain notifications for historical reference.

Related Articles

• Members
• Invitations
• Audit Logs
• Workspaces
• Dashboard Overview

Next Steps

Now that you understand how users receive important updates, continue with Audit Logs to learn how SaaSStinger Lite records security-sensitive events for accountability and traceability.