Platform · Complex Organizations
Your company is not flat. Your identity system shouldn't be either.
Real organizations have holding companies, regions, subsidiaries, divisions, and teams inside teams — and they run dozens of applications across all of it. Most platforms flatten that into one tenant with a member list, so the real structure ends up in a spreadsheet and every new app starts from zero. Axowl holds the shape you actually have, and every application that runs inside it: one directory, one login, one database plane, one sealed history — from the first row in Postgres to the commit that ships the front end. The unit that carries all of it is called an App Group .
See pricing Talk to sales
Structure Account → Org → Sub-org → Team
Applications Unlimited · dev + production each
Surface Directory · database · deploy
directory for the whole group
one person, one record, every app
∞
levels of team depth
01 · 01.01 · 01.01.02 — as deep as the real org
passkey domain
enroll a device once, sign in anywhere in the group
seams between systems
config, data, and access share one chain
01 · The problem
Fragmentation doesn't announce itself. It arrives one application at a time.
Nobody chooses a fragmented stack. It accumulates: a second product needs its own login, a subsidiary needs its own tenant, a client project needs its own database. Two years later the company is running eleven applications and nobody can say who has access to what.
One person becomes three people
Each application carries its own user pool, so a customer who uses three of your products holds three accounts, three passwords, and three passkey enrollments. Support cannot tell they are the same human. Neither can your billing, your analytics, or your offboarding process.
The org chart lives in a spreadsheet
The platform models one flat tenant with a list of members, so divisions, dotted-line reporting, and approval order are maintained by hand somewhere else. That file drifts within weeks of the first reorganization, and every access review after it inherits the drift.
Nobody can answer "who changed this"
Configuration sits in one console, data in a database, source in a repository, releases in a CI tool. Four systems, four logs, four retention policies — and the seam between them is exactly where an answer goes missing when a regulator or a customer asks.
02 · Structure
Five levels, because that's how companies are actually built.
A holding company with four operating companies is not the same shape as a startup with two teams, and neither fits a flat member list. Axowl models the organization on five levels, and you move up a level for exactly one reason: how separately the money and the operations run.
multiple
Accounts
Legally separate entities. Separate books, separate ownership, separate everything.
Account
The ownership and billing root
Who owns the tenancy, who pays for it, and who can transfer it. One owner, deliberately.
Org — a region or an operating company
Its own payments, its own plan, its own admins. Korea, EMEA, and the logistics subsidiary each sit here.
01.01
Sub-org — one level down, still its own budget
The deepest level that spends money on its own. A business unit that runs its own P&L belongs here.
01.01.02
Team — nested without limit, billed at zero
Division inside division inside squad. Depth is free, so scale is handled here instead of by splitting tenants.
Unit codes are derived from the tree, not typed in. Move a department and every code beneath it recalculates.
Account Group headquarters — ownership, billing, transfer
Org A region or operating company — independent payments
Sub-org A business unit with its own budget
Team Nested to any depth, shares the parent's plan
03 · Lines & badges
Every company has lines the org chart never shows.
People report to more than one manager. Approvals travel a fixed order and stall when someone is on leave. Contractors, service accounts, and AI agents act inside your systems every day without appearing anywhere in HR. A structure that ignores all of that is a diagram, not a control.
Reporting lines, including the dotted ones
A solid line to a functional manager, a dotted line into a project, a reference line to a compliance officer — all three coexist as relationships between badges, with cycle protection and a depth limit so a bad import cannot loop the tree. Permissions follow membership, so a person who joins a team inherits what the team holds instead of collecting a personal pile of grants.
Approval lines that carry a seal
An approval line says who signs, in what order, and what happens when a step is skipped or delegated. Each step is stamped by the badge that approved it and sealed into a tamper-evident chain, so the record of an approval survives the reorganization, the departure, and the audit that comes two years later.
Service accounts and AI agents carry badges here too — with their own roster, scoped permissions, a TTL, and a sealed lifecycle. Meet AI Agent Control
04 · Applications
Add the eleventh application. Configure nothing.
Applications join a group and inherit what the group already carries. There is no second directory to reconcile, no login screen to rebuild, and no passkey to enroll again — and each application still gets its own development and production environments under the same roof.
Shared directory
A person signs up once and reaches every application in the group. One human, one record.
One passkey domain
The group shares a relying-party ID, so a device enrolled in one app authenticates across all of them.
One hosted login
Social, passkey, magic link, and password are enabled once at the group and served to every app.
One brand & defense
Icon, colors, hero copy, and bot protection are set at the group. Change them in one place, everywhere.
The group's own configuration is a sealed record. Turning on a login method or changing a relying-party ID is an event with an actor and a timestamp, not a silent toggle.
05 · One chain, end to end
From the first row in Postgres to the commit that ships the app.
An App Group is not only an identity boundary. It is the unit that owns the database the console reads from, the permissions that reach it, the audit chain that records every change, and — next — the attestation that binds a released bundle back to the commit it came from.
Directory & badges
Every actor in the group, with the teams and lines they belong to.
Shipping
Permissions
One scope grammar across the group, with deny taking precedence and conflicts refused before a grant lands.
Shipping
Database
A sealed Postgres attached to the group — or connect the database you already run and start with a read-only rung.
Shipping
Sealed history
Config changes, grants, approvals, and writes land in one tamper-evident chain that an administrator cannot rewrite.
Shipping
Code & deploy
A released bundle attested back to its commit and its author's badge, then verified in the visitor's own browser.
In design
Steps 01–04 are in the product today. Step 05 — deploy attestation — is in design: it reuses the same seal chain and the same badges, and it targets the failure the industry keeps meeting head-on, where the code a visitor's browser executes is not the code the team reviewed. We would rather name that line than blur it.
06 · The alternative
The same applications. One structure instead of eleven.
Capability
Axowl App Group
Per-app tenants stitched together
✓ native · △ partial or add-on · ✕ not the model Comparison describes general capabilities of each product category, not any specific commercial offering.
07 · In practice
Three shapes this fits well
A group with several operating companies
Each operating company becomes an org with its own payments and admins; shared services live in teams below. Headquarters reads a consolidated view without anyone building a mega-tenant that no interface can render.
An agency running client applications
One App Group per client keeps identities, databases, and audit chains genuinely separate, while your own staff carry a single badge across all of them. Handover at the end of an engagement is a transfer, not a migration.
A SaaS company with a product suite
Every product in the suite shares one customer directory, one login, and one passkey domain, so a customer who adopts a second product signs in with the account they already have — and you stop paying twice for the same person.
One structure. Every application inside it.
Bring us your org chart — the real one, with the subsidiaries and the dotted lines — and we will map it onto App Groups with you before you write a line of code.
Talk to sales How App Groups work