Multi-tenant government platforms face a trust question that private SaaS never confronts at the same intensity: the tenants are municipalities whose data relationship with each other is formally competitive, politically sensitive, and occasionally adversarial — one municipality's collection strategies, debtor lists, and enforcement patterns are exactly what another municipality should never see. Most platforms answer with application-layer courtesy: the interface filters by the user's municipality, and everyone agrees not to look. The failure modes are predictable — a report bug, an export edge case, a cached dashboard — and each one leaks another tenant's ledger. Storage-layer separation answers differently: every model is partitioned per province and municipality at the storage level itself, so the question "can user A see municipality B's invoices" is not enforced by disciplined code but by the fact that the rows physically live in different partitions with tenant isolation enforced automatically by the platform.
The three layers that must agree #
- Storage partitioning: rows separated per municipality at the storage layer — the physical guarantee.
- Server-side secure filters: every read filtered on the server, un-bypassable by the client — collectors see only their own assignments, managers what they review.
- Granular RBAC with field-level stripping: sensitive field groups removed server-side from unauthorized roles, not hidden in the interface.
The distinction that matters to auditors is where the enforcement lives. Interface-level filtering is a promise; server-side filtering is a mechanism; storage-level partitioning is a fact. When every read is filtered server-side and cannot be bypassed, the attack surface shrinks to the authorization rules themselves — which are reviewable — instead of the entire application's discipline, which is not. Multi-user profiles complete the model: one identity holds many app-scoped profiles (admin, sub-admin, manager/reviewer, collector), each with its role bundle, geographic scope, and language, so a person who serves two municipalities does so through two scoped profiles rather than one over-privileged account. Hardened authentication — JWT sessions with token blacklisting, HMAC-signed anti-replay mobile requests, integration tokens for ministries, OTP and SSO — wraps the whole structure, and the full audit trail records every task change so that "who could have seen this" always has a precise answer.
For procurement, the test is disarmingly simple to ask and hard to fake: "Show me a query, as a municipality-A admin, for municipality-B invoices — not through your interface, through your database." Platforms with courtesy-layer separation reach for explanations; platforms with storage-layer separation demonstrate the empty result set. Government data architecture should be judged by what it physically cannot do, because everything else is a version of asking nicely.