Sell a connected product to more than one customer and you inherit a set of problems that have nothing to do with sensors: separate accounts, separate users, separate branding, and a boundary between them that has to hold every time. OmniCloud was built multi-tenant from the framework up, so onboarding the next customer is a provisioning step rather than another deployment to maintain.
Three different starting points, one shared requirement. A product serving more than one customer organisation needs the boundary built in rather than added in the release after somebody notices.
Each of your customers needs their own account, their own devices and their own users, and none of them should be able to see the others. That requirement arrives with the second customer, not the fiftieth, and it is expensive to bolt onto a dashboard that assumed one.
You deliver to many end customers and need to move between them yourself without ever mixing their data. The hardware you install belongs to them, the visibility belongs to you, and both need to be true at once.
Regional teams, acquired brands and customer-facing divisions each need a scoped view of the same platform. Running ten separate deployments to achieve that is a maintenance bill nobody budgets for twice.
Tenancy is not one feature. It reaches into data access, permissions, branding, the API and billing, and these are the parts of it that are running in production today.
Accounts nest. A distributor account sits above its customers, an operator account sits above its sites, and every query, report and export is scoped to the account context rather than to a filter the application has to remember.
Owner, admin, operator and viewer inside an account, with a parent account able to grant no more than it holds itself. A permission cannot be escalated by moving a user between accounts, which is the failure mode that actually happens in production.
A device belongs to one account and can be shared with another. The operator owns the hardware, their service provider sees the units they maintain, and neither party has to buy the device twice or hand over a login.
The same build serves several brands, resolved from the hostname it is reached on, with its own name, logo and palette. This is how a second product brand runs today on the same platform as the first one.
The same platform ships as iOS and Android apps published under your own developer account, with your name and icon on the store listing, maintained for the life of the product.
Service tokens are scoped to an account and to a permission set, so an integration cannot reach further than the account it was issued for. The API covers what the dashboard covers, including control commands.
Thresholds, alert routing, report definitions, units and language are set per account. The build is shared and the behaviour is not, so a customer asking for one thing to be different does not become a branch you maintain forever.
Products, subscriptions, rate plans and usage records are modelled per account, so entitlement and consumption are answerable per customer rather than reconstructed from a spreadsheet at the end of a quarter.
Choosing between the two is a decision you live with for the life of the product, and it is far cheaper to make now than to revisit. Laid out side by side.
| Multi-tenant (OmnIoT) | Single-tenant | |
|---|---|---|
| Data isolation | Tenant boundary enforced by framework. Impossible to query across tenants accidentally. | One shared database. Isolation is a filter the application code must remember. |
| Onboarding a new customer | Provision a tenant in seconds, configured from a template. | A new deployment, a new environment, a new operational burden. |
| Branding | Per-tenant logo, colors, domain, email identity. | One brand. Customers see your name, not theirs. |
| Permissions | Roles are scoped to a tenant. Operators see a super-admin view. | Flat permission model. Cross-customer concerns mix in the codebase. |
| Billing | Per-tenant metering, invoicing, pricing tiers. | One customer. One invoice. No primitives for the second one. |
| When this is the right choice | You are building a product sold to many end customers. | You are building a product for yourself or a single internal deployment. |
Multi-tenancy looks like a filter on a query until somebody tries to retrofit it. These are the parts that make it a platform-level problem rather than a feature.
Every query, every search, every report, every join, every aggregation, has to include the tenant context. A missing tenant filter is a data leak. Retrofitting this onto a single-tenant codebase is painful; building it in at the framework layer from day one is the only reliable approach.
Customers want "just this one thing different." Without a config-driven platform, each tweak becomes a branch; six months later you have ten deployments and no shared updates. A real multi-tenant platform makes tenant customization a config problem, not a code problem.
Spinning up a new tenant must be a single operator action. Tearing one down must preserve audit logs, handle billing cleanup, and delete customer data per your data-retention policy. Automating both is a months-long subsystem if you build it yourself.
When a tenant reports a bug, your logs must let you reproduce the exact tenant state. Tenant context has to flow through every trace, log line, and metric. This is observability plumbing that takes real engineering effort.
It means one deployment serves many separate customer organisations, each with its own data, users, devices, branding and configuration, and with a hard boundary between them. A single-tenant platform serves one organisation. Any connected product sold to more than one customer needs the first shape, and the requirement arrives with customer number two.
Isolation is logical rather than physical: one database, with every query scoped to the account context at the framework level rather than by a filter each piece of application code has to remember. That is cheaper to run, faster to onboard into, and it is the boundary the platform enforces. If your customers arrive with a specific isolation requirement in writing, send it over and we will tell you how it maps.
Yes. The same build resolves its brand from the hostname it is served on, including name, logo and colour system, and that is running in production today for more than one brand. The mobile apps are published under your own developer identity with your name on the listing.
Products, subscriptions, rate plans and usage records are modelled per account, so what a given customer is entitled to and what they have consumed are both answerable from the platform, and invoicing runs from that data. Tell us which billing stack you already run and we will tell you how it connects.
Yes. Thresholds, alert routing, reports, units, language and enabled features are per account. The build is shared and the behaviour is not, which is what keeps a customer-specific request from becoming a branch you maintain for years.
Hard enough that it is worth avoiding. Account context has to be threaded through every query, every permission check and every export, and a single missed one is a data leak rather than a bug. The work is measured in engineer-months, and it is the reason this was built in from the start rather than added when the second customer arrived.
Yes. The app resolves the account and the brand from the login, so a user in one account never sees another. For what the mobile side involves, see our page on branded mobile apps.
How many of them there are, what each one needs to see, and where they disagree with each other about how the product should behave. We come back with how that maps onto accounts, roles and per-account configuration, and where it does not.
Talk to us →