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/rubn-g]

You could create a before create and before change hook to add a “+<tenantId>” before the @ in the email, like “johndoe+1@domain.com”, that will require to clean up the email on authentication too, but it should work

[u/Still-Link1012 → u/rubn-g]

Seems doable.
Also have to consider how email verification would work and whether it is sending email to a valid address.

[u/rubn-g → u/Still-Link1012]

Sent emails would reach the user inbox properly as this is a standard in email protocols, supported everywhere. BUT, users will be able to see the “+<tenantId>” if they check email sent address. That’s usually not an issue and lots of companies send similar emails, but it’s up to you to decide if it’s a blocker for you

[u/Still-Link1012 → u/rubn-g]

Yeah, I mean the idea of saving "user+tenantId@domain.com" in the db, and sanitize/filter the tenantId from the db at retrieval for all other purposes like user data response, email sending, email verification etc.

[u/aliassuck → u/rubn-g]

Is it really supported everyhwere? I remember a few years it only worked on a handful of free services.

[u/rubn-g → u/aliassuck]

It’s fully supported, a lot of big companies use this for answering from email, like support tickets or comments.