Platform admin vs. org admin: waarom het onderscheid telt

“Admin” is een overbeladen woord in een multi-tenant platform. Het platform heeft admins. Elke tenant-org heeft admins. Ze delen het woord, maar niet de macht. De URL-structuur van het platform maakt het onderscheid zichtbaar.

Platform-only pages

/admin/platform/trust-scoring (platform-wide trust scoring weights configureren), /admin/escrow/disputes (disputes over tenants heen adjudicaten), /admin/auction/strikes/[companyId] (strikes kwijtschelden — alleen platform-staff), /admin/exchange-rates (rate feed beheren). Deze pagina’s worden gated door getAdminScope() die een platform-tier role teruggeeft; een org-admin kan ze niet bereiken, ongeacht de eigen permissions.

Org-only pages

/admin/organizations/[slug] (eigen org settings, users, billing beheren), /admin/users (eigen org-users beheren), /admin/storage (eigen storage tier), /admin/email-provider (eigen outbound email config). Deze pagina’s laten een org-admin alles binnen de eigen tenancy doen zonder andere tenants te zien.

Cross-tenant zichtbaarheid

Platform staff kan tenantoverschrijdend lezen voor supportredenen — een klant maakt een ticket over een deal die vastliep, platform staff moet de deal kunnen zien om te onderzoeken. Die zichtbaarheid wordt gelogd: elke cross-tenant read schrijft een entry in de activity log met de staff user, target tenant en action. Dus “heeft iemand van het platform naar onze data gekeken?” heeft een antwoord dat geen gok is.

Waarom twee URL-prefixen

Omdat platform-only pages en org-only pages in dezelfde URL-tree nestelen leidt tot access-control mistakes. /admin/platform/* is ondubbelzinnig. /admin/organizations/* is ondubbelzinnig. Bij een pagina op /admin/[ambiguous-name] moet je code lezen om te weten welke rol hem handhaaft. Naamgeving maakt audit eenvoudiger.