Members

A member is a user who belongs to a workspace.

While a user represents an individual's identity, a member represents that user's relationship with a specific workspace.

This distinction is fundamental to SaaSStinger Lite's multi-tenant architecture.

What You'll Learn

In this guide you'll learn:

• What a member is
• How memberships work
• Why memberships are stored separately
• How roles are assigned
• How membership lifecycle works
• Best practices for managing members

Users vs Members

One of the most common misconceptions in multi-tenant applications is treating users and members as the same thing.

They are not.

User
 ├── Identity
 ├── Email
 ├── Display Name
 └── Profile

            │

            ▼

Membership
 ├── Workspace
 ├── Role
 ├── Joined Date
 └── Status

A single user can have multiple memberships.

Each membership belongs to exactly one workspace.

Architecture Note

SaaSStinger Lite intentionally separates user identity from workspace membership.

This allows one user to collaborate across multiple organizations while maintaining a single profile.

Membership Collection

Memberships are stored in their own Firestore collection.

Each membership links a user to a workspace.

Typical relationships look like:

User A
    │
    ├───────────────┐
    ▼               ▼
Membership      Membership
    │               │
    ▼               ▼
Workspace A    Workspace B

Likewise:

Workspace
      │
      ├────────── Member
      ├────────── Member
      ├────────── Member
      └────────── Member

This creates a many-to-many relationship between users and workspaces.

Membership Document

A membership document typically contains:

{
  id: string
  userId: string
  workspaceId: string
  role: "OWNER" | "ADMIN" | "MEMBER"
  createdAt: Timestamp
}

Each membership is uniquely identified using:

userId_workspaceId

This guarantees that a user cannot accidentally join the same workspace multiple times.

Membership Creation

Memberships are created automatically in two situations.

During Onboarding

When a new user creates their first workspace:

1. Workspace created
2. Membership created
3. Role assigned as OWNER
4. Usage initialized
5. Dashboard loaded

Accepting an Invitation

When an invited user accepts an invitation:

1. Invitation validated
2. User authenticated
3. Membership created
4. Invitation marked as accepted
5. Workspace becomes available

Roles

Each membership has exactly one role.

Available roles are:

OWNER

The highest level of access.

Owners can:

• Manage workspace settings
• Invite members
• Change roles
• Remove members
• Transfer ownership
• Delete the workspace

ADMIN

Administrators help manage the workspace.

Typical permissions include:

• Invite members
• Manage projects
• Manage teams
• Moderate workspace activity

Administrators cannot perform owner-only operations.

MEMBER

Members have access to the workspace but with limited administrative privileges.

Typical permissions include:

• Access assigned projects
• Create tasks
• View shared resources
• Collaborate with teammates

Membership Lifecycle

Memberships follow a predictable lifecycle.

Invitation Sent
       │
       ▼
Invitation Accepted
       │
       ▼
Membership Created
       │
       ▼
User Collaborates
       │
       ▼
Role Updated (optional)
       │
       ▼
Membership Removed

Removing Members

When a member is removed:

• Membership document is deleted.
• Workspace access ends immediately.
• Protected routes prevent further access.
• Firestore Security Rules deny future requests.

Removing a membership does not delete the user's account.

The user may still belong to other workspaces.

Membership Verification

Every privileged operation should verify that the authenticated user has a valid membership.

Typical flow:

Request
    │
    ▼
Authenticated User
    │
    ▼
Membership Exists?
    │
 ┌──┴──┐
 │     │
Yes    No
 │      │
 ▼      ▼
Continue Deny Access

This verification occurs before business logic is executed.

Security Note

Never assume that an authenticated user belongs to a workspace.

Always verify membership before allowing access to protected resources.

Displaying Members

The Members page allows workspace administrators to:

• View current members
• View assigned roles
• Invite new members
• Change member roles
• Remove members

Because membership information is stored separately from user profiles, the application can efficiently retrieve workspace-specific data without duplicating user information.

Relationship to Invitations

Invitations and memberships are closely related.

An invitation represents a pending relationship.

A membership represents an active relationship.

Invitation
      │
Accepted
      │
      ▼
Membership

Once an invitation has been accepted, it is no longer used for authorization.

The membership becomes the source of truth.

Best Practices

• Use memberships for authorization.
• Keep user identity separate from workspace relationships.
• Assign the minimum required role.
• Verify membership server-side.
• Remove memberships instead of deleting user accounts.

Common Mistakes

Storing Roles in the User Profile

Roles belong to a workspace.

A user may have different roles in different workspaces.

Store roles in memberships—not user profiles.

Using Email as Authorization

Email identifies the user.

Membership determines what the user can access.

Always authorize using memberships.

Trusting Client Role Information

Never rely on a role supplied by the browser.

Verify the authenticated user's membership and role on the server before performing privileged operations.

Related Articles

• User Profiles
• Workspaces
• Invitations
• RBAC & Permissions
• Audit Logs

Next Steps

Now that you understand how users become members of a workspace, continue with Invitations to learn how SaaSStinger Lite securely invites new users and creates memberships through a controlled onboarding process.