Sooner or later, every growing charging operation stops being one organisation. A council brings in district partners. An operator signs franchisees. A hardware brand launches an operated service for its dealers. A workplace provider runs hundreds of employers' sites. Suddenly the question isn't "can the platform manage chargers?" but "can the platform manage organisations — without them seeing each other?"
That's multi-tenancy, and it's one of those architectural properties that's nearly invisible when done well and catastrophic when bolted on. Here's what it actually involves, and how to probe for the difference.
What a tenant is
A tenant is an organisational boundary inside the platform: its own sites and chargers, its own users and roles, its own tariffs, branding and reporting — logically sealed from every other tenant. The operator of the platform sees across tenants; each tenant sees only itself.
The deceptively hard part is that tenancy touches everything. It's not a tenant_id column added to the chargers table; it's a boundary that must hold across:
- Data queries — every list, report, export and search scoped, always, with no path around it
- Permissions — roles that exist within a tenant, plus platform-level roles that legitimately cross tenants (your NOC, your support desk)
- Events — webhooks and streams that deliver each tenant only its own telemetry
- Branding — white-label theming, domains and sender addresses per tenant
- Aggregates — the subtle one: caches, dashboards, counters and search indexes that were computed fleet-wide and now must not leak totals across the boundary
Where retrofits leak
Platforms that grew single-tenant and added tenancy later exhibit a recognisable pattern of seams. The boundary holds on the main screens — the chargers list, the sessions table — because those got audited. It leaks in the corners:
- The CSV export that ignores the scope filter the UI applied
- The autocomplete that suggests another tenant's site names
- The password-reset email that arrives with the platform's default branding
- The webhook configured before tenancy landed, still firing fleet-wide
- The "total network size" figure on a dashboard quietly answering a question the tenant shouldn't be able to ask
None of these are exotic attacks — they're ordinary features that predate the boundary. Which is the argument for tenancy as a foundation: when every query path, event route and template is born scoped, there are no pre-boundary corners to leak from.
The operator's eye view
Multi-tenancy done properly is also what makes the platform operator's job tractable:
- Cross-tenant operations with per-tenant blast radius. A firmware rollout can target one tenant's estate, or all tenants in cohorts — with the audit trail recording which. An incident in one tenant's integration stays their incident.
- Delegated administration. Each tenant manages its own users and roles within limits you set — your team stops being the helpdesk for every partner's password reset.
- Honest per-tenant reporting. Utilisation, uptime and revenue per tenant, computed from the same scoped data the tenant themselves sees — so the numbers in your commercial reviews match the numbers in their portal, always.
How to test a platform's claim
Vendors all say "multi-tenant". Fifteen minutes of demo probing separates the answers:
- Ask for two tenants live, side by side. Log in as each. Then try the corners: exports, search, autocomplete, a webhook payload. Ask to see the same charger list as tenant admin and as platform operator.
- Ask where the boundary is enforced. "In the UI" is the wrong answer. You want scoping in the platform's data access layer and API — the UI merely inherits it. (Ask: if I call the API with tenant A's credentials and tenant B's charger ID, what exactly happens? The right answer is a 404, not a 403 — don't even confirm the resource exists.)
- Ask how platform staff access is controlled and logged. Cross-tenant visibility is legitimate and necessary — and precisely why it must be role-gated and audit-trailed. Who looked across the boundary, when, at what?
- Ask what's shared by design. Honest platforms have a short, deliberate list (platform status, aggregate anonymised benchmarks, perhaps roaming interconnects). Evasive ones haven't thought about it — which means the list exists anyway, unwritten.
The takeaway
Multi-tenancy is the difference between a charging platform and a charging business platform. If your growth involves partners, sub-brands, franchises or public-sector consortiums — and almost everyone's does eventually — the tenant boundary is load-bearing infrastructure. Probe it like you'd probe the electrical design: before you build on it.
AmpNexus is multi-tenant at the platform layer — tenant isolation, delegated roles and per-tenant white-labelling as configuration, not customisation. See the Portal or book a demo.