Multi-Tenancy
TL;DR
A software architecture where one system instance serves multiple isolated organizations (tenants), each seeing only their own data.
Multi-tenancy is the difference between "one installation per shop" (old MSP/PMS model) and "one SaaS, many shops, complete isolation." In a multi-tenant system, every customer's data is partitioned at the database level and surfaced through access controls that prevent leakage between tenants.
For a repair-shop platform, multi-tenancy enables: organizations (your business entity), stores (locations within the org), and users (with roles per org and store). One owner with three locations sees one dashboard; their employees see only the locations they're assigned to.
Done well, multi-tenancy is invisible. Done badly, it leaks data between tenants — a category of bug that turns into a customer-exodus event when discovered.
Quick answers
Is my data isolated from other shops on the platform?
Yes. Get Repair uses Postgres row-level security with organization_id partitioning. Every query is scoped to the user's org context at the database level — the application code physically cannot return another org's rows.
Can I have multiple organizations under one login?
Yes — for owners who run unrelated businesses (e.g. a repair shop and a separate retail shop). Switch orgs from the user menu; permissions are scoped per org.