Skip to main content

Multi-Tenant Membership

Users in MeetLoyd exist outside of any single tenant. They connect to tenants through memberships -- a model familiar from Slack, GitHub, and Notion. One user can belong to multiple organizations, each with its own role, data, and settings.

How Memberships Work

A membership is a link between a user and a tenant. Each membership record contains:

FieldDescription
User IDThe user's global identity
Tenant IDThe tenant (organization) they belong to
RoleTheir role within that tenant
Is DefaultWhether this is their primary workspace

A single user can have as many memberships as needed. Each membership is independent -- being an owner in one tenant does not grant any access in another.

Roles Per Tenant

Each membership carries its own role. The same person can hold different roles in different tenants (e.g., owner of their own company, admin at a client, member at a partner).

RoleDescription
OwnerFull access including billing and tenant management
AdminFull access except billing and tenant deletion
AI EngineerTechnical focus: agents, tools, workflows
MemberStandard access for daily operations
ViewerRead-only access

Roles are assigned per membership. Changing your role in one tenant has no effect on your role in another.

Login Flow

Single membership: If a user belongs to only one tenant, login proceeds directly into that workspace. No extra step is required.

Multiple memberships: If a user belongs to multiple tenants, the dashboard displays a tenant picker so the user can choose which workspace to enter. The default membership is pre-selected for convenience.

Tenant Switching

Users with multiple memberships can switch between tenants without logging out. In the dashboard, tenant switching is available from the user dropdown menu in the top-right corner. The menu lists all tenants the user belongs to, with the active tenant highlighted. Clicking another tenant triggers the switch and reloads the workspace context.

Switching issues a fresh JWT scoped to the selected tenant. The previous token remains valid until it expires but is no longer used by the dashboard.

Invite Flow

When a user is invited to a new tenant:

  1. The tenant admin sends an invite (email or link)
  2. If the user already has a MeetLoyd account, accepting the invite creates a new membership linking them to the inviting tenant
  3. If the user is new, they create an account first, then the membership is created
  4. Existing memberships are never modified or overwritten -- the new membership is additive

Invitations expire after 7 days.

Data Isolation

Every JWT carries a single tenant ID. All database queries are automatically scoped to that tenant. There is no mechanism for a single API request to access data across tenants.

  • Switching tenants changes the JWT, which changes the query scope
  • Agents, teams, apps, conversations, files, and all other resources are isolated per tenant
  • Audit logs record which tenant context was active for every action
  • Even users with memberships in multiple tenants cannot query across boundaries

Platform Tenant

MeetLoyd maintains an internal workspace called the platform tenant, used for internal support, R&D, and platform administration. MeetLoyd staff may have a membership in the platform tenant alongside customer tenants for support purposes. The same isolation rules apply -- being in the platform tenant grants no special access to customer data.

Membership Audit Log

Every membership change is recorded in a tamper-evident audit log:

ActionDescription
JoinedUser accepted an invitation
LeftUser voluntarily left the tenant
RemovedAdmin removed a member
Role ChangedMember role was updated
SwitchedUser switched active tenant
InvitedAdmin sent an invitation

Admins can view the audit log from Settings > Members or via the membership audit endpoint.

Best Practices
  • Set a default tenant for quick login -- the default membership is pre-selected in the tenant picker
  • Use descriptive tenant names to avoid confusion when switching (e.g., "Acme Corp - Production" instead of "Workspace 2")
  • Parent company admins should be viewer or admin in subsidiary tenants -- reserve the owner role for people who manage billing and settings for that specific organization
  • Revoke memberships promptly when users leave an organization
  • Audit membership changes regularly using the audit log
  • Use invitations instead of direct membership creation for a proper audit trail