L0product

Multi-Tenant Routing

Customer org signs in and sees only their data via URL-scoped routes. The routing layer that makes multi-tenancy real for users, not just the database.

1,200

Priority Score

Pain × Demand × Edge × Trend × Conversion

Customer Journey

Why should I care?

Five cards that sell the dream

1Why

One URL separates your data.

What happens when Solar365 signs in and sees Dreamineering's CRM?

The friction: DB-level multi-tenancy exists. Org schema, scoped queries, membership model — all working. But every route is flat under /(app)/. Sign in as Solar365, see Dreamineering's data.

The desire: /org/solar365/dashboard. /org/solar365/crm. Every URL carries the org context. The auth adapter validates membership before rendering a single byte.

The proof: Vercel, Linear, Notion all use this exact pattern. The DB layer is done. This is routing.

The routing map

Picture

Two office buildings side by side, each glowing a different color — one sees into the other through a shared glass wall. A URL bar floats between them showing /org/solar365/. Dark, cinematic, 16:9

2Evidence

The database already knows.

How do you know the data isolation layer works?

Layer	State	Evidence
Schema	Working	org_organisation.slug unique + indexed
Multi-org	Working	Composite unique on (externalAuthId, organisationId)
Query scoping	Working	All repos accept organisationId via ApplicationContext
Org switching	Tested	Integration test proves data visibility changes with org switch
URL routing	Missing	All routes flat under /(app)/*

The isolation stories

Picture

A database diagram glowing green — org_organisation with slug field highlighted, system_user with composite unique constraint visible. Terminal showing passing integration tests. Dark, cinematic, 16:9

3How

Layout resolves. Children render.

Where does the org context enter the system?

One layout component at /org/[slug]/layout.tsx. It resolves the slug to an org ID, validates user membership, and sets the org context. Every child route inherits it.

The auth adapter extends to accept org from URL params. Same ApplicationContext interface. Every server action works unchanged — they already receive organisationId from context.

The context flow

Picture

A funnel diagram: URL slug at the top, flowing through 'validate membership' gate, into ApplicationContext, feeding all child routes below. One entry point, many destinations. Dark, cinematic, 16:9

4Risk

One bug means data leakage.

What is the worst thing that can happen?

The hardest thing: The org context switch. Today validateContext() queries system_user.limit(1). Tomorrow it must accept org from URL params. One mismatch between URL and query context = data leakage.

Kill signal: Solar365 creates a contact. If that contact appears in Dreamineering's CRM, halt everything. Fail closed, not open. Redirect beats exposure.

Picture

A red warning screen showing 'CROSS-TENANT DATA EXPOSURE' with two org names side by side. A lock icon cracked open. Dark, crimson highlights, cinematic, 16:9

5Ship

Revenue requires routing.

What does this unblock?

$0 revenue. Solar365 has an org in the database. They cannot sign in and see their data. This PRD is the gate between a platform that works for one org and a platform that works for customers.

5 build items. All presentation-layer. No schema migrations. The hardest part — data isolation — is already done.

Picture

A key turning in a lock, behind it a dashboard glowing with Solar365 branding. A revenue counter starting from $0. Dark, golden highlights, cinematic, 16:9

1 / 5

Above: why the customer should care. Below: why the builder should care.

Feature Dev Journey

How do we build it?

Five cards that sell the process

1Job

Route before render.

What is the single job this PRD solves?

Resolve org context from the URL before any child route renders. One layout, one guard, one context — every downstream component inherits.

1 / 5

Kill Signal

Solar365 signs in, creates a contact in CRM. If contact appears in Dreamineering's CRM, data isolation failed — halt everything.

Questions

If the URL says /org/solar365/ but the auth adapter returns Dreamineering's org ID, which one wins — and how do you detect the mismatch before data leaks?

Should the org layout guard fail open (render with fallback) or fail closed (redirect to picker)? Cross-tenant exposure is worse than a redirect loop.
When a user's org membership is revoked, what happens to their active session at /org/[that-slug]/?
Is the org slug the right URL token, or should it be org ID? Slugs are readable but can change. IDs are stable but ugly.

Multi-Tenant Routing

Why should I care?

One URL separates your data.

The database already knows.

Layout resolves. Children render.

One bug means data leakage.

Revenue requires routing.

How do we build it?

Route before render.

Five moments of truth.

Five items. Zero migrations.

Cross-tenant = zero bytes.

Presentation, not plumbing.

Kill Signal

Questions