Tenancy below the application
If isolation depends on every query remembering a filter, it will eventually be forgotten once — and once is enough. Enforcing it underneath makes the mistake impossible rather than unlikely.
Reference build — 03
Multi-tenant platform and admin console
Web Platforms & SaaS
The problem
A growing product keeps customer data in one shared schema, handles permissions in application code, and requires an engineer to run a query whenever the support team needs an answer.
The approach
Enforce tenancy at the data layer rather than trusting every query to remember it, so a missed filter cannot leak across customers. Move permissions into a role model checked in one place. Then give support and operations their own console, so the questions that used to reach engineering are answered by the people who have them.
The outcome
Support answers its own questions, engineering stops running ad-hoc queries, and adding a customer is configuration rather than a migration.
Decisions worth explaining
Permissions in one place
Checks scattered through the codebase cannot be audited or changed with confidence. A single role model can be read in one sitting and tested directly.
Support gets its own tools
Every ad-hoc database query run on a customer’s behalf is both an interruption and a risk. A console with the right permissions removes both.
Recognise your problem here?
The specifics will differ, but the shape usually does not. Tell us what you are dealing with and we will tell you how we would approach it.