Audit Logs

Audit logs provide a permanent record of important activity inside a workspace.

They allow administrators to understand:

• Who performed an action
• What action occurred
• Which resource was affected
• When the activity happened
• Additional context about the operation

SaaSStinger Lite uses audit logs to improve security, accountability, and operational visibility.

What You'll Learn

In this guide you'll learn:

• Why audit logs exist
• What events are recorded
• How audit records are structured
• Who can access audit logs
• How exports work
• Best practices for audit logging

Why Audit Logs Matter

Modern SaaS applications need visibility into important changes.

Examples:

• A member was removed
• A role was changed
• A project was deleted
• Workspace settings were modified

Without audit logs, administrators have no reliable way to investigate these events.

Audit logs provide an immutable history of administrative activity.

Audit Log Architecture

Audit logs belong to a workspace.

Workspace
      │
      ▼
Audit Logs
      │
      ├── Actor
      ├── Action
      ├── Target
      ├── Metadata
      └── Timestamp

Every event is associated with the workspace where it occurred.

Architecture Note

Audit logs are separate from application activity feeds and notifications.

Notifications inform users about events.

Audit logs provide a permanent administrative record.

Audit Record Structure

Each audit log entry contains:

{
  id: string

  workspaceId: string

  userId: string

  action: string

  targetType: string

  targetId: string

  metadata: object

  createdAt: Timestamp
}

Audit Fields

workspaceId

Identifies the workspace where the event occurred.

This ensures audit history remains isolated between organizations.

userId

Identifies the user who performed the action.

This provides accountability by connecting actions to authenticated users.

action

Describes what happened.

Examples:

WORKSPACE_UPDATED
MEMBER_INVITED
ROLE_CHANGED
PROJECT_CREATED

targetType

Identifies the resource affected.

Examples:

workspace
member
invitation
project

targetId

References the specific resource involved in the action.

For example:

project_12345
member_67890

metadata

Stores additional context about the event.

Examples:

{
  "oldRole": "MEMBER",
  "newRole": "ADMIN"
}

Metadata allows events to provide more detail without changing the core audit schema.

Audited Events

SaaSStinger Lite records important administrative actions.

Currently audited events include:

Workspace Events

• Workspace created
• Workspace updated
• Workspace deleted

Invitation Events

• Invitation created
• Invitation accepted
• Invitation revoked

Membership Events

• Member added
• Member removed
• Membership changes

Role Changes

Changes to workspace permissions are recorded.

Examples:

MEMBER → ADMIN
ADMIN → MEMBER

Project Events

Project lifecycle events are audited.

Examples:

• Project created
• Project updated
• Project deleted

Administrative Actions

Other workspace-level administrative operations can also generate audit records.

Audit Log Access

Audit logs contain sensitive workspace information.

Access is restricted to:

• OWNER
• ADMIN

Regular workspace members cannot view administrative audit history.

Authorization Flow

Before displaying audit logs:

User Request
      │
      ▼
Authenticate User
      │
      ▼
Verify Workspace Membership
      │
      ▼
Check Role
      │
      ▼
OWNER or ADMIN?
      │
      ▼
Allow Access

Unauthorized users are denied access.

Audit Logs Are Permanent

Audit logs cannot be deleted.

This provides:

• Accountability
• Historical visibility
• Security investigation support
• Compliance preparation

Removing audit records would weaken the reliability of the security history.

Security Note

Audit logs should be treated as append-only records.

New events can be created, but historical records should not be modified or removed.

Exporting Audit Logs

Administrators can export audit history as CSV files.

Exporting allows teams to:

• Review activity externally
• Archive records
• Perform security reviews
• Prepare compliance documentation

Audit Logs vs Notifications

These systems solve different problems.

A single event may generate both an audit log and a notification.

Audit Logging Flow

User Action
      │
      ▼
Server Validation
      │
      ▼
Business Operation
      │
      ▼
Audit Record Created
      │
      ▼
Stored in Firestore

Audit logs are created from trusted server-side operations rather than directly from client components.

Best Practices

• Create audit logs from server-side logic.
• Never allow users to modify audit history.
• Include enough metadata to explain important changes.
• Keep audit events workspace-scoped.
• Restrict access to trusted administrators.

Common Mistakes

Logging Only Successful UI Actions

A user interface can be bypassed.

Always create audit logs after verified server operations.

Storing Sensitive Data

Avoid storing unnecessary private information inside metadata.

Only store information required to understand the event.

Allowing Users to Delete Logs

Audit history loses value if users can remove records.

Keep logs append-only.

Future Extensions

Future versions may introduce:

• Advanced filtering
• Date range searches
• Additional export formats
• Compliance reporting
• Security dashboards

The current architecture provides the foundation for these improvements.

Related Articles

• RBAC & Permissions
• Notifications
• Members
• Workspaces
• Security Guide

Next Steps

You now understand the major security and collaboration systems inside SaaSStinger Lite.

Continue with Dashboard Overview to learn how these features come together into the main application experience.