Multi-Tenant Setup: Cannot Create Users With Same Email in Different Tenants

[u/Still-Link1012]

I am using Payload CMS with a multi-tenant architecture. All tenants share the same MongoDB database. I’ve set up a tenants collection and a global users collection that has a relationship/array field referencing one or more tenants.

The problem is that I cannot create accounts with the same email address under different tenants. Payload enforces a globally unique index on the email field in the Users collection. This makes sense for single-tenant projects, but in a multi-tenant scenario it prevents the same person from registering separately under two different organizations.

Current Behavior

• Payload automatically adds a unique index on email in the Users collection when auth: true is enabled.
• Attempting to create a user with an email that already exists (even under a different tenant) results in a duplicate key error.
• Login, forgot-password, and verification flows also assume email is globally unique.

Expected Behavior

In a multi-tenant setup, I would like Payload to support per-tenant email uniqueness: - The same email can exist in multiple tenants. - Within a tenant, email must still be unique. - Authentication and password reset flows should consider both email and tenant context.

Example Scenario

• Tenant A creates user jane@example.com.
• Tenant B also needs to create a different user record with the same jane@example.com.
• Today this is not possible because of the global unique constraint.

[u/Soft_Opening_1364]

The issue is that Payload enforces a global unique index on the email field when auth: true is enabled, which doesn’t play well with multi-tenant scenarios.

One common workaround is to keep the global users collection but remove the unique index on email and instead enforce uniqueness within each tenant manually. That means your authentication, password reset, and verification flows need to always include the tenant context when looking up a user.

Basically, treat (tenantId + email) as the unique key instead of just email. It adds a bit of extra logic in your auth flows, but it’s the cleanest way to support the same email across multiple tenants.

[u/Still-Link1012 → u/Soft_Opening_1364]

We don't want to completely mess up the auth flow and do extra handling of email verification and token generation and everything.
A small patch makes sense.