When to Use Multi-Tenant vs Access Control in Payload CMS: A Decision Framework

I recently worked on a project where we needed to consolidate four separate division websites into one unified platform using Payload CMS. The question came up early: should we use Payload's multi-tenant plugin or stick with built-in access control and tagging? It seemed like a straightforward question, but the answer revealed some common misconceptions about what multi-tenant architecture actually does.

This guide walks through the technical reality of both approaches and provides a practical framework for making the right choice for your project.

Understanding the Common Scenario

When you're building a CMS for an organization with multiple divisions, brands, or departments, the architecture question comes up immediately. Maybe you're consolidating separate websites like electronics.company.com, signs.company.com, and lighting.company.com into one platform. Or perhaps you're building a new site where different teams need to manage their own content.

The multi-tenant plugin sounds like it's designed exactly for this scenario. After all, you have multiple "tenants" in the form of divisions or departments. But here's where the confusion often starts.

What Multi-Tenant Actually Does

Payload's multi-tenant plugin doesn't create separate databases or schemas. It works within a single database by adding a tenant field to your collections and automatically enforcing tenant-based filtering and access control.

When you enable multi-tenant on a collection, Payload adds a relationship field that connects each document to a specific tenant. Then it automatically filters queries and applies access control based on which tenant the user belongs to. The key architectural characteristic is that each piece of content belongs to exactly one tenant. A project document lives in the Electronics tenant or the Signs tenant, but not both.

This creates what I call "logical isolation within a shared database." All your data lives in the same place technically, but the plugin enforces boundaries that make it behave like separate systems from the user's perspective.

What Access Control and Tagging Does

Payload's built-in access control lets you define granular permissions on collections and fields without enforcing any structural isolation. You write functions that determine who can read, create, update, or delete documents based on user properties, document data, or any custom logic you need.

Combined with a simple tagging approach where you add a divisions field to your collections, you get organizational structure without enforced boundaries. A project can be tagged with both Electronics and Signs. A user can have permissions to see multiple divisions. Content naturally crosses organizational lines when it needs to.

This is what I call "flexible permissions with shared data." Everything lives together, and you control access through logic rather than structural isolation.

The Decision Criteria

The choice between these approaches comes down to one fundamental question: do you need isolation or do you need flexibility?

Multi-tenant is appropriate when you're building separate experiences that happen to share infrastructure. Think about a SaaS platform where Company A and Company B are both customers. They're using the same application, but they should never see each other's data. Each company needs its own isolated space. When you access the admin panel, you're working in one tenant's context, and switching tenants means moving to a completely different data space.

Access control with tagging is appropriate when you're building one experience with different permission levels. Think about a company website where the Electronics division and Signs division are both part of the same organization. Projects might involve both divisions. Users might need to see across divisions. The admin panel shows you filtered views based on your permissions, but you're all working in the same shared space.

The technical indicator is whether your content should ever belong to multiple organizational units simultaneously. If a piece of content could legitimately be tagged with Electronics and Signs, you don't want multi-tenant because it forces you to pick one. If content should strictly belong to one tenant and never appear in another tenant's space, multi-tenant gives you that guarantee.

Walking Through a Real Scenario

Let's work through a concrete example. Imagine you're consolidating four division websites into one unified platform. The divisions are Electronics, Traditional Signs, Lighting and Service, and a lighting product brand. The goal stated in the requirements is to create a unified, cohesive, modern online platform.

The first question is about the domain strategy. Are you building one unified company.com where users can discover all offerings in one place? Or are you building separate subdomains like electronics.company.com and signs.company.com where each division maintains its own distinct web presence?

If it's one unified domain, multi-tenant works against you. Here's why. A user searches for "pylon signs" on your site. Some pylons are traditional signs, others include LED displays from the Electronics division. With multi-tenant, that LED pylon project must belong to either Electronics or Signs, not both. You'd need to duplicate content or build complex workarounds to show it in both divisions' portfolios. With tagging, you simply tag the project with both Electronics and Signs, and it appears naturally in both filtered views.

The second question is about user workflows. Will your content managers need to work across divisions, or is each division completely separate? If someone from Electronics should never see Signs content and vice versa, that's isolation. But if it's common for projects to involve multiple divisions, or if senior staff need visibility across the organization, that's flexibility.

The third question is about future requirements. Sometimes teams want multi-tenant because they're thinking ahead to customer portals or partner portals. This is where clarification becomes critical. If the portal means customers log in to see their own projects in an isolated space at customer.company.com, that's a valid multi-tenant use case. But if the portal means partners log in to access a shared knowledge base with appropriate read permissions, that's just role-based access control. You don't need multi-tenant for that.

In the consolidation scenario, the requirements point toward access control and tagging. One unified domain, content that crosses divisions, users who need flexibility. Multi-tenant would enforce isolation that conflicts with the stated goal of a cohesive platform.

The Access Control Implementation Approach

When you go with access control and tagging, the implementation is straightforward. You add a divisions field to collections that need organizational structure. This field allows multiple selections so content can belong to Electronics, Signs, or both.

In your users collection, you track which division each user belongs to and what their role is. An admin sees everything. An Electronics user sees only content where the divisions field includes Electronics. You implement this with access control functions on your collections.

For the admin UI, you can add filters that let users view content by division. The global admin sees all content with filtering options. Division users see their content by default but might see cross-divisional content based on your business rules.

For the public website, you query content by division tags when displaying division-specific pages, but you can also show content across divisions when that makes sense for discovery.

When Multi-Tenant Is the Right Choice

Multi-tenant shines in specific scenarios. If you're building a platform where different companies or organizations use your system, you need true isolation. A marketing agency managing websites for competing clients needs multi-tenant so Client A never sees Client B's content. Each client might even access the system at their own subdomain.

If you're building separate brand websites that happen to share a CMS, multi-tenant gives you clean separation. Brand A and Brand B might be owned by the same parent company but compete in the market. They need their own spaces.

If regulatory or competitive requirements demand data isolation, multi-tenant enforces those boundaries at the architectural level. You're not relying on permission logic being correct. The structure itself prevents cross-tenant access.

If you're planning separate subdomains from the start where each subdomain is truly independent, multi-tenant aligns with that architecture naturally.

The Bottom Line

The choice between multi-tenant and access control isn't about which is better. It's about which matches your requirements. Multi-tenant enforces isolation, access control provides flexibility. Both are powerful in the right context.

When you're building one unified platform where content might cross organizational boundaries, start with access control and tagging. It's simpler, more flexible, and aligns with that use case. When you're building separate isolated spaces that happen to share infrastructure, use multi-tenant. It enforces the boundaries you need.

The consolidation scenario we walked through is one of the most common cases where teams consider multi-tenant but actually need access control. If that sounds like your project, you now have a framework for making the decision confidently.

If you found this helpful or have questions about your specific use case, let me know in the comments. I'd love to hear about the architectural decisions you're working through. And subscribe for more practical Payload CMS guides.

Thanks, Matija