Invitations

Invitations allow workspace members to collaborate securely without manually creating accounts or assigning permissions.

Rather than adding users directly to a workspace, SaaSStinger Lite uses a dedicated invitation workflow. This ensures every new member is authenticated, verified, and explicitly accepts the invitation before gaining access.

What You'll Learn

In this guide you'll learn:

• How invitations work
• The invitation lifecycle
• How existing and new users join a workspace
• How memberships are created
• How invitations are revoked
• Best practices for invitation security

Why Invitations?

Adding users directly to a workspace creates several problems.

• You cannot verify ownership of the email address.
• Users may never complete registration.
• Permissions may be assigned incorrectly.
• There is no audit trail.

Instead, SaaSStinger Lite treats invitations as pending workspace memberships.

Only after an invitation is accepted does the user become a member.

Invitation Lifecycle

Create Invitation
        │
        ▼
Invitation Stored
        │
        ▼
Invitation Link Shared
        │
        ▼
User Opens Link
        │
        ▼
Authenticated?
   ┌────┴────┐
   │         │
  No        Yes
   │         │
Login/Register
   │
   ▼
Return to Invitation
        │
        ▼
Validate Invitation
        │
        ▼
Create Membership
        │
        ▼
Mark Invitation Accepted
        │
        ▼
Open Dashboard

Architecture Note

Invitations are temporary onboarding records.

Memberships are permanent authorization records.

Once an invitation has been accepted, the membership becomes the source of truth for workspace access.

Creating an Invitation

Workspace users with the appropriate permissions can invite another user by entering their email address.

The invitation is stored and associated with the target workspace.

At this stage, the invited user does not yet have access.

Access is granted only after the invitation has been accepted.

Invitation Document

Each invitation stores the information required to complete onboarding.

Typical fields include:

{
  token: string
  workspaceId: string
  email: string
  role: "ADMIN" | "MEMBER"
  status: "PENDING" | "ACCEPTED" | "REVOKED"
  createdAt: Timestamp
}

The invitation token is used as the Firestore document ID.

Invitation Links

Invitation links follow this pattern:

/invite/{token}

The token uniquely identifies the invitation.

When opened, SaaSStinger Lite validates that the invitation exists before continuing.

Existing Users

If the invited email already belongs to an existing SaaSStinger Lite account:

1. The user signs in (if necessary).
2. The invitation is validated.
3. A membership is created.
4. The invitation is marked as accepted.
5. The workspace becomes immediately available.

No additional registration is required.

New Users

If the invited person does not yet have an account:

1. They open the invitation link.
2. They are redirected to register or sign in.
3. Authentication is completed.
4. They return to the invitation.
5. The invitation is validated.
6. A membership is created.
7. The dashboard opens with the new workspace available.

This creates a smooth onboarding experience without losing the original invitation context.

Invitation Validation

Before an invitation can be accepted, SaaSStinger Lite validates:

• The invitation exists.
• The invitation has not been revoked.
• The authenticated user's email matches the invited email.
• The invitation has not already been accepted.

Only after these checks pass is a membership created.

Security Note

Invitation acceptance is tied to the authenticated user's email address.

A signed-in user cannot accept an invitation intended for a different email account.

Invitation Expiration

By default, invitations do not expire.

An invitation remains valid until one of the following occurs:

• It is accepted.
• It is revoked.

This simplifies collaboration and avoids unnecessary re-invitations.

If your application requires time-limited invitations, you can extend the invitation model with an expiration timestamp.

Revoking Invitations

Workspace administrators can revoke pending invitations.

When an invitation is revoked:

• It can no longer be accepted.
• No membership is created.
• The invitation remains available for auditing.

Revoking an invitation does not affect existing members.

Creating Memberships

Accepting an invitation automatically creates a membership.

The membership links:

• the authenticated user
• the target workspace
• the assigned role

After creation, authorization is handled entirely through the membership.

The invitation is no longer used for permission checks.

Authorization

Invitations do not grant permissions.

Only memberships authorize access.

This distinction keeps onboarding separate from authorization and reduces the risk of accidental privilege escalation.

Audit Trail

Invitation activity should be recorded in the workspace audit log.

Typical events include:

• Invitation created
• Invitation accepted
• Invitation revoked

These records help administrators understand how workspace membership has changed over time.

Best Practices

• Invite users by email address.
• Assign the minimum required role.
• Validate invitations server-side.
• Create memberships only after successful validation.
• Record invitation activity in audit logs.

Common Mistakes

Treating Invitations as Permissions

Invitations are temporary onboarding records.

Permissions always come from memberships.

Skipping Email Validation

Always ensure the authenticated user's email matches the invited email before creating a membership.

Allowing Duplicate Memberships

Before creating a membership, verify that the user is not already a member of the workspace.

Related Articles

• Members
• Workspaces
• RBAC & Permissions
• Authentication
• Audit Logs

Next Steps

Now that you understand how users join workspaces, continue with RBAC & Permissions to learn how SaaSStinger Lite authorizes actions using workspace roles and layered security.