Architecture Principle · 03 of 9
Multi-tenancy Native
Multi-tenancy is built into the data model and the query layer — not bolted on at the application layer. Tenant A literally cannot see Tenant B's data, even if a developer makes a mistake.
What this means
In practice.
Mill Group with 5 subsidiaries runs on one deployment with strict data isolation
Users see only the companies and branches they're authorized for
Cross-company transactions (inter-company sales) handled with proper journals on both sides
Per-company feature toggles, branding, currency, and fiscal calendar
How it works
Under the hood.
Tenant column
Every business table has company_id and branch_id columns. Indexes ensure efficient filtering.
Query interceptor
Every query auto-injected with WHERE company_id = $user_company. Developers cannot forget — it's enforced.
Row-level security
PostgreSQL RLS policies provide defense-in-depth at the database layer.
Tenant context
JWT tokens carry tenant context. Switching companies requires re-authentication or explicit elevation.
Visual
Tenant isolation matrix
Same deployment, fully isolated data planes. No cross-tenant queries possible.
Real-World Example
Real-world: 3-company group, 12 branches
Before
Mill group had separate ERP installations per subsidiary. Consolidating P&L took 5 days post month-close.
After
All 3 companies on one Papyrus deployment with strict isolation. Group dashboard shows consolidated P&L live. Month-close takes 1 day.
Ready to modernize your mill?
See Papyrus BPApp
in your mill.
Book a personalized demo. We'll walk through every module relevant to your operation — from Deckle optimization to GSTR-3B compliance.