A tenant in Payload CMS should represent a durable isolation boundary in your business domain, something like a company, region, or independently operated organization. It should never simply mean "whoever owns this record." Confusing ownership with tenancy is the second architectural mistake I see teams make after they've already decided they need multi-tenancy, and it costs far more to fix later than it does to get right up front. This article walks through how to identify the correct tenant using a durability test, why users and clients often get mistaken for tenants, and how to separate identity, membership, and business data so the model holds up as your application grows.
I recently worked through this exact question while reviewing the architecture of a Payload CMS application for a client. Internal users were creating records for different external clients, and the team's first instinct was to make each user or client a tenant so their data would stay isolated. That instinct is understandable, and Payload makes it technically easy to do. It's also, in most cases I've seen, the wrong move.
I've already covered the broader decision of whether to reach for multi-tenancy at all in When to Use Multi-Tenant vs Access Control in Payload CMS. That article focuses on whether your system needs structural isolation or flexible permissions. This one goes a level deeper, into what should actually fill the tenant slot once you've decided you need one.
Why This Question Comes Up
Picture an internal proposal-management application. You have authenticated users:
text
Salesperson A
Salesperson B
Sales Manager
Administrator
And you have proposals:
text
Proposal 1 → Client A
Proposal 2 → Client B
Proposal 3 → Client C
Each salesperson mostly works with their own proposals, and one salesperson's proposal should never leak into another's view. Multi-tenancy looks like an obvious fit here. You could model it as:
text
Tenant: Salesperson A
Proposal 1
Proposal 2
Tenant: Salesperson B
Proposal 3
Proposal 4
Payload's multi-tenant plugin will happily give you tenant-aware filtering and isolation around that structure. Before wiring it up, ask a more fundamental question: is a salesperson actually a tenant in this business? Usually the answer is no. A salesperson owns or manages a record. That's an authorization relationship, and it deserves its own model rather than being forced into the tenant abstraction.
What the Multi-Tenant Plugin Actually Introduces
Payload's official multi-tenant plugin does more than add a permission check. Once enabled on a collection, each document gains a relationship to a tenant, and Payload uses that tenant context to filter records, relationships, and Admin Panel views across the app.
Your data ends up shaped like this:
text
Tenant A
Pages
Projects
Proposals
Media
Tenant B
Pages
Projects
Proposals
Media
That structure earns its place when Tenant A and Tenant B are genuinely separate spaces, for example:
text
Acme Corp Australia
Acme Corp Europe
or
text
Agency Client A
Agency Client B
or
text
Franchise A
Franchise B
Those entities carry durable meaning. Users join them, leave them, get reassigned within them, and the entity itself keeps existing regardless. That persistence is what separates a tenant from a "user responsible for this record."
Ownership Is Not Tenancy
Consider a proposals collection modeled around ownership instead of tenancy:
This tells Payload "user owns proposal," and it stops there. It doesn't claim the user is an isolated organization, which means you can layer in managers who see their team's proposals, admins who see everything, reassignment between salespeople, or temporary collaboration, all without touching what a tenant means in your system.
The Problem With Making Users the Tenant
Modeling a user as a tenant tends to work fine on day one. The trouble shows up later, once the abstraction has already spread through your access rules, your relationships, and your Admin Panel views, and the business asks for something the model never anticipated.
Say you set tenant = salesperson today. Six months in, the business expands the platform and the real requirement turns out to be:
text
tenant = Australia
tenant = Europe
or
text
tenant = Corporate
tenant = SME
or
text
tenant = Brokerage A
tenant = Brokerage B
Now two different concepts are competing for the same architectural slot. The records that were scoped around individual salespeople actually belong inside a larger organizational tenant. What you had:
text
Salesperson A
Proposal 1
Proposal 2
needed to be:
text
Acme Corp Australia
Salesperson A
Salesperson B
Proposal 1
Proposal 2
Proposal 3
The salesperson was a user inside the tenant the whole time. Untangling that means migrating tenant relationships, rewriting access rules, restructuring memberships, and revisiting every tenant-enabled collection in the system. This is why I steer teams away from reaching for multi-tenancy just because two users shouldn't see the same records. That's an authorization problem, and solving it with a domain-isolation mechanism creates work you'll eventually have to unwind.
Ask What Will Still Be True in Three Years
The most reliable way to find the correct tenant is to look for the most durable boundary in your domain.
People change jobs. Salespeople inherit accounts from colleagues who leave. Managers move between teams. Customers get reassigned to new account managers. Records shift owners constantly. Every one of those changes is a sign you're looking at ownership or authorization, not tenancy.
A true tenant holds steady through all of that. Take:
text
Acme Corporation
users
projects
invoices
files
If Sarah leaves Acme and John takes her place, Acme is still the tenant. The same holds for:
text
European Division
users
proposals
media
Users move around inside that structure freely, and the tenant's meaning never changes underneath them. That gives you a useful test: if this user disappeared tomorrow, would the tenant still conceptually exist? When the answer is no, you're looking at something other than a tenant.
Clients Are Not Automatically Tenants Either
The same mistake shows up with customers. Picture an internal CRM where employees create proposals for hundreds of external clients. You could set up:
text
Tenant: Client A
Tenant: Client B
Tenant: Client C
If those clients never log into the application and never operate their own workspace, ask what the tenancy layer is actually accomplishing. A client relationship usually models cleanly as:
text
Proposal
client
owner
content
status
with public access to that proposal handled independently, through something like a secure token URL:
text
/proposals/secure-token-abc
Keeping Client A from seeing Client B's proposal is a security requirement, and it's satisfiable without turning either client into a CMS tenant. The access boundary around a public document and the tenancy boundary of your CMS are related, but they're not the same concern, and collapsing them together is where the confusion starts.
When the Client Really Is a Tenant
Making the client the tenant becomes the right call once each customer logs in and manages a real workspace:
text
Their users
Their projects
Their media
Their settings
Their reports
The architecture then looks like:
text
Client A
User 1
User 2
Projects
Documents
Client B
User 3
User 4
Projects
Documents
Client A operating inside Client B's context should be impossible by design, and that's the signal you're dealing with a genuine tenancy boundary. Client A represents an independent organizational context inside the application, and that's the property that qualifies it as a tenant, not the fact that its data needs to stay secure.
A Broker Can Be a Tenant, but Only If "Broker" Means an Organization
Terminology muddies this more than almost anything else. Suppose the requirement reads: "Each broker must only see their own customers." If "broker" means an individual salesperson employed by the same company, that's user-level authorization, same as the salesperson example above.
If "broker" means an independent brokerage firm running on your platform, the picture changes:
text
Brokerage A
Broker User 1
Broker User 2
Clients
Proposals
Brokerage B
Broker User 3
Broker User 4
Clients
Proposals
Here, Brokerage A is a sensible tenant, and the individual broker users are simply members of it. This is exactly why the question to ask isn't "should brokers be tenants?" It's "what business entity does this record actually represent, and is that entity an independent data boundary?"
Ownership vs. Tenancy at a Glance
Signal in the requirement
What it usually means
How to model it
"This person owns/manages the record"
Ownership
relationship field + access control
"This person may or may not see the record"
Authorization
Access control based on role or relationship
"This organization has its own isolated users and data"
Tenancy
Payload multi-tenant plugin
The entity survives staff turnover unchanged
Tenancy
Payload multi-tenant plugin
The entity disappears if one user leaves
Ownership or authorization
Standard collection + access control
Separate Identity, Membership, and Business Data
Once you have real tenants, a related principle becomes important: identity, authorization, and business data are three separate concepts, and mixing them causes problems later.
A person exists globally:
text
User: Sarah
and can hold access to:
text
Tenant A
Tenant B
while the actual business records stay tenant-scoped. I walked through a concrete implementation problem that comes from collapsing these concepts together in Why Payload CMS Users Should Never Be Tenant-Scoped.
The practical model looks like this:
text
Global identity
↓
Tenant membership
↓
Tenant-scoped business records
This matters most for administrators, consultants, agency staff, and anyone else who legitimately works across multiple tenant contexts. The tenant stays the organizational boundary. The user stays the human operating inside it.
A Better Decision Sequence
I now split Payload multi-tenancy into two separate decisions, and I make them in order.
1. Do I actually need tenancy?
This is the question I cover in my multi-tenant vs access-control decision framework. If the requirement is really about flexible permissions inside one shared organization, standard access control is usually enough. Genuinely isolated spaces sharing the same infrastructure call for multi-tenancy.
2. What represents the tenant?
Resist the pull toward the user, client, department, or record owner as a default. Look for the durable business boundary instead. A good tenant candidate tends to show several of these traits:
text
It represents an organization or persistent workspace.
It can contain multiple users.
It owns business data independently.
Users can join or leave without destroying its meaning.
Cross-tenant movement is unusual rather than routine.
Its records should normally stay isolated from other tenants.
It is likely to remain a meaningful boundary as the application grows.
The more of these hold true, the more confidence you can have in the tenant you've picked.
A Simple Example
Take this requirement: "We have 30 salespeople. Each salesperson creates proposals for their clients, and salespeople should normally only see their own proposals. Managers need to see everything."
I'd model this as:
text
Users
role
manager/team
Proposals
owner
client
and enforce the restriction through access control, with no tenant in sight.
Now change the requirement: "The platform will be licensed to 20 independent brokerage companies. Each brokerage has its own employees and clients and must never access another brokerage's data." The architecture shifts naturally to:
Same general application. A completely different domain boundary drives the tenant decision, and that's the piece worth getting right before you touch the plugin.
FAQ
Can a single application use multiple tenant types, like both regions and clients?
Yes, though it usually means you need a hierarchy rather than two flat tenant collections. Model the outer boundary (region, for instance) as the tenant, and nest client-level scoping inside it through relationships or access control rather than a second tenant layer.
What happens if I've already built tenant = user and need to migrate to tenant = organization?
Plan for a data migration that inserts an organization layer above your existing users, reassigns tenant-scoped records to the new organization tenant, and rewrites access rules that assumed a one-to-one relationship between user and tenant. This is exactly the rework the durability test is meant to help you avoid.
Does every collection in a multi-tenant Payload app need to be tenant-scoped?
No. Only collections that hold data belonging to a specific isolated organization need the tenant relationship. Shared reference data, global settings, and cross-tenant admin tooling often stay outside the tenant boundary entirely.
How do I handle a user who legitimately needs access to more than one tenant, like a consultant or agency staff member?
Keep identity global and model tenant access as a membership relationship rather than tying the user record itself to a single tenant.
Is it ever fine to start with tenant = user as a placeholder and fix it later?
It can work for a genuine single-tenant prototype you plan to throw away, but treat it as a placeholder explicitly rather than a real architectural decision. If there's any chance the app grows into multiple real organizations, model ownership through a relationship field from the start and add tenancy only when an actual isolation boundary shows up.
Conclusion
Choosing the multi-tenant plugin over access control is only the first decision. Choosing what fills the tenant slot is the one that determines whether your architecture still makes sense a year from now. A salesperson, account owner, or individual user can need strongly restricted access without qualifying as a tenant, and treating them as one locks an ownership concept into a boundary you'll likely need later for something more fundamental, like a company, region, business unit, or independent customer organization.
Start by deciding whether you need tenancy at all. Then apply the durability test to find the boundary that will still hold in three years. Get both right, and the Payload implementation becomes far easier to reason about as the application grows.
