Govern
Isolation enforced from the token
Multi-tenancy is easy to claim and expensive to retrofit. The scoping decision here is made once, at the edge of every request, from a cryptographically verified claim, and nothing downstream is allowed to widen it.
How a request gets its scope
The whole model rests on one rule, so it is worth stating exactly.
Tenant identity comes from the verified token. Never from the body, the query string, or the path.
An action at login attaches the tenant to the token itself. Every request is authorised by reading that claim after signature verification; a mismatch between the claim and what the caller asked for is refused outright. There is no code path in the customer API that can address another tenant’s data, because the scope is not something a request is able to state.
One organisation per tenant
Each customer is a separate organisation in the identity provider, with its own membership and invitation flow. That is also the seam where an enterprise connection would attach for a customer who wants to bring their own directory.
Standards, not a bespoke login
OpenID Connect with PKCE across web and mobile. Multi-factor, invitations and account recovery are handled by the identity provider rather than reimplemented by us, which is the right place for them to live.
Isolation all the way down
The tenant is part of the partition key in the record store, the object-storage prefix, the graph query filter and the index that maps a live websocket connection back to its owner. It is not a filter applied at the end.
Administration is a separate surface
Powoflow administration runs on its own user directory and its own audience. A customer administrator and a platform administrator are different identities with different tokens, one cannot become the other.
Roles, stated accurately
Inside a tenant there are two roles today: administrator and viewer. That is the honest description. Granular per-module, per-record permissions are a common expectation and we do not want anyone discovering the gap during an evaluation.
What does exist alongside them is a competency register in the projects module, skills with validity windows and evidence, which gates who may be assigned to particular work. It solves a different problem from role-based access control and does not substitute for it.
Modules, and what 'off' means
Four optional modules
Work orders, projects, inventory and data explorer can each be enabled or not. Assets are never gateable. The graph is Powoflow, and there is no version of this product without it.
Off is commercial, not operational
With a module off, existing data stays readable and work already under way can still be completed. What stops is creating new objects in that module. Nobody is ever locked out of finishing a job because of a billing state.
Entitlement failures fail open
If the entitlement service cannot be reached, the last known-good answer applies. A platform problem on our side must never look like a lockout on yours.
White-label branding
A tenant can carry its own logo and identity, which is what makes Powoflow workable for service providers running it on behalf of their own customers.
Sharing outside the tenant
Publishing something to someone without an account is where tenant isolation usually springs a leak. The public sharing surface runs as a separate application against a separate data store, and the credentials it holds name that one store and nothing else, so even a total compromise of the public side reaches no tenant data.
A component that can read both stores exists, but it is internal, never reachable from the network, and copies only an explicit allow-list of fields. Sharing is opt-in per asset and per facet, and anything not shared answers identically to something that does not exist.
Bring your security questionnaire
This is the page we would rather argue about early. If your answer to isolation is stricter than ours, we want to hear it before a pilot, not after.