Platform · Tenancy, identity & subscriptions
One login across every app, with access decided per tenant
One3 is designed so a person has one login for every company they work with, while roles, records, fields, seats and subscriptions are checked on every action.
One login, many tenants
Agency staff, consultants, chartered accountants and group-company employees often work across several companies. In One3 they get one global account (one password or passkey, one MFA setup) and one membership per tenant.
- Login is global; authorisation is always per tenant. A session is bound to one active tenant at a time. Switching tenant mints a new tenant-scoped token.
- Your roles, preferences and audit trail in tenant A are never visible in tenant B.
- Leaving a tenant ends the membership. Your account survives.
- A tenant with enterprise SSO can require its members to sign in through its own identity provider when they access that tenant.
- Agency staff reach client sub-accounts through delegated, fully audited partner memberships, never shared passwords.
The hierarchy is simple: an optional Partner (agency or reseller) owns many Tenants. A tenant is the data-isolation, billing and subscription boundary. Inside a tenant, Workspaces separate business units, brands, regions or legal entities. Tenants subscribe to Apps and Modules.
Sign-in methods
| Method | Who | Notes |
|---|---|---|
| Passkeys (WebAuthn) | All users; the recommended default | Phishing-resistant |
| Email + password | Workforce users unless SSO is enforced | Breached-password check, rate limits, lockout with backoff |
| Authenticator app (TOTP) | All users | Admins can require MFA for everyone or for admin roles |
| SMS / WhatsApp OTP | Portal users and frontline staff without email | Lower assurance; not allowed for admin roles |
| Google / Microsoft sign-in | SMB users, portal candidates | Linked to the global account by verified email |
| Enterprise SSO (SAML 2.0 / OIDC) | Business and Enterprise plans | Per-tenant identity provider |
| Magic link | Portal users, invited approvers | Short-lived and single-use |
Enterprise SSO and SCIM
Designed for IT teams that run their own identity provider. SSO is planned in the Year-1 build; SCIM 2.0 is planned for W3.
Home-realm discovery
Enter your email and One3 routes you to your company's identity provider based on a verified domain.
SSO enforcement
When enforced, members can open that tenant only with an SSO-authenticated session, even if they use a password elsewhere.
Domain verification
A DNS TXT proof is required before a tenant can claim an email domain for SSO or auto-join.
SCIM 2.0 provisioning
Create, update and deactivate memberships and groups from your directory. Groups map to roles.
Fast deprovisioning
Removing someone in the IdP suspends their membership within one sync cycle and revokes sessions for that tenant immediately.
Break-glass accounts
Each SSO-enforced tenant keeps at least two local admin accounts with passkeys. Using them triggers alerts.
UI hiding is a convenience, never the control
Every layer is evaluated in the Action Bus for writes and in the query layer for reads. List and read filters are compiled into SQL predicates, and field-level security is applied as a projection mask when the query is built. Role changes take effect within seconds through versioned permission sets, without waiting for tokens to expire.
Roles, records and duties
Permissions are generated from each Pack's Actions and named {app}.{module}.{object}.{action}.
Built-in roles per app
Each app ships roles such as HR Admin, Recruiter, Payroll Approver or Sales Rep. They are versioned with the Pack and can be cloned.
Custom roles and groups
Tenant admins build roles from permissions of subscribed modules and assign them to people or groups.
Record-level access
Ownership, manager hierarchy, workspace scope, explicit sharing, queues and portal relationships decide which records you see.
Field-level security
Sensitive fields such as salary and bank details are masked unless a role grants them.
Separation of duties
The person who prepares a pay run cannot approve it. The creator of a vendor cannot approve a payment to it. Checked at assignment and at Action time.
Step-up for high-risk actions
Payroll approval, payments, signing, deletion and admin role grants need a fresh passkey or TOTP check.
Digital Employees act inside your permissions
Digital Employees, service accounts, API keys and MCP clients are non-human identities with their own audit trail.
An agent's effective permissions are its granted skills ∩ its human owner's permissions ∩ tenant entitlements ∩ its autonomy level per skill. For rented or agency-operated agents, they are also bounded by a client-issued mandate that only the client tenant can grant.
- Agents use short-lived workload tokens, never passwords.
- An agent can never approve an Action it proposed and can never hold an approver permission for R4 Actions.
- If the owner loses a permission or leaves, the agent loses it too; ownership must be reassigned or the agent is paused.
- Mandates name explicit Actions, record scopes, providers, spend and risk caps, and expire. They are checked again right before every externally visible or irreversible Action, and revocation stops queued work everywhere.
- MCP clients connect with OAuth and PKCE. R3 and R4 Actions still need approval inside One3.
License and seat types
| Type | Who | Counted as |
|---|---|---|
| Full user | People who work in an app daily, such as sales reps, recruiters and support agents | One seat in each app where assigned |
| Light user | Self-service employees, approvers, interviewers, occasional viewers | Platform-wide light seat |
| Portal user | Customers, candidates, vendors and partners | Usage meter or free within plan limits |
| Agent seat | Rented or tenant-built Digital Employees | Per agent identity, per app used |
| Service / API | Integrations and service accounts | Usage meters, not seats |
How subscriptions become entitlements
One3 compiles what a tenant has bought into versioned entitlement rows that every enforcement point reads.
- 1
Subscribe
A plan plus app subscriptions, module add-ons, standalone modules, seat packs, usage allowances, agent rentals or marketplace add-ons.
- 2
Compile
A deterministic compiler turns subscriptions, trials, agency allocations and overrides into entitlement rows with a new version.
- 3
Enforce
The Action Bus is authoritative for writes, the query layer for reads, and workflows, agents and connectors re-check at each step.
- 4
Handle limits fairly
Hard limits return a clear error; soft limits warn admins. After a lapse, modules turn read-only for a grace period and exports are always allowed.
- 5
Keep data on change
Cross-app relations are kept regardless of entitlement, so resubscribing restores context. Upgrading a standalone module to the full app keeps all data.
Portal users are kept separate
Candidates, customers, vendors and partners sign in on a separate portal domain with their own client and cookies. Portal tokens can never call workforce APIs, and portal access is narrow and relationship-based: a candidate reads their own applications, a customer contact reads their own company's tickets and invoices.
Identity in plan numbers
- global login per person
- 1
- authorisation layers
- 6
- sign-in methods
- 7
- license and seat types
- 5
- isolation tiers, pooled to sovereign
- 4
Questions about identity and access
Can one person work across several client companies?
Yes. That is the design: one global account with one membership per tenant. Each session is bound to one active tenant, and switching mints a new token.
Can One3 support staff log in as us?
Not by default. Support access needs a ticket, tenant admin consent with a scope and duration, a support-specific identity, a visible banner and a full audit trail. Emergency access without consent is limited to security incidents, needs two One3 approvers and is disclosed afterwards.
Do we pay for every employee in every app?
No. The plan uses per-app full seats for daily users plus a platform-wide light seat for self-service, approvals and occasional use. Prices are not set in the plan.
What happens to a Digital Employee if its owner leaves?
It loses the owner's permissions at the next permission version. Ownership must be reassigned within a grace period, or the agent is paused.
Can we see who changed a role or a permission?
Yes. Identity, access and subscription changes are designed to write append-only, hash-chained audit events that admins can filter, export and, on Enterprise, stream to a SIEM.
Plan your access model with us
Talk to us about SSO, roles, seats and how One3 plans to keep every person and agent within the right boundaries.