# Tenancy and identity

URL: /products/app/tenancy-and-identity · Id: `page:products/app/tenancy-and-identity`

> How an App keeps each Customer's records apart and decides who may sign in and act there, people and agents alike.

Each [Customer](/business/nouns/customer) of an [App](/business/nouns/app) gets its own [Tenant](/business/nouns/tenant): a partition of records, keys and [Settings](/business/nouns/setting) no other Customer reaches. Inside it, every [Person](/business/nouns/person) and agent holds a [Persona](/business/nouns/persona) and an [Access Level](/business/nouns/access-level).

## One Tenant per Customer
[`Tenant.provision`](/business/nouns/tenant/provision) runs when a party accepts an [Offer](/business/nouns/offer). It creates the Tenant, its keys and defaults, and an invitation for its first admin, in one [Action](/business/nouns/action).

Riverside Property's Tenant holds its leases, its people and its plan. A query with its key never returns a Harbor Residential record, whatever the filter. The Tenant's data belongs to Riverside Property; Leaseline operates it.

A Customer's team is the Tenant's members. The App has no separate account, team or company record to keep in step.

## Personas
A Persona is who signs in and the job they come to do. Leaseline's App declares two: `manager`, who renews and notifies, and `resident`, who reads a lease and answers a notice.

Each Persona holds a [Role](/business/nouns/role), and the Role holds the [Permissions](/business/nouns/permission): which [Verbs](/business/nouns/verb) it may call on which [Nouns](/business/nouns/noun). The App reads that chain, so two Personas in one Tenant see two different Apps from one definition.

## Members and Access Levels
[`Tenant.invite`](/business/nouns/tenant/invite) asks a person to join. When the Offer prices per member, the invite resizes the [Subscription](/business/nouns/subscription) and prorates it.

| Access Level | May |
| --- | --- |
| `owner` | Every Verb, one-way Verbs included, each within its delay window |
| `admin` | Every two-way change, access included; one-way Verbs stay with the owner |
| `member` | Every two-way change, except to the Nouns that decide access |
| `viewer` | Read, and change nothing |

An Access Level is a preset of Permissions, never a Role. A Persona says what job someone does; an Access Level says how much of the Tenant they run.

## Sign-in
People sign in with a passkey or an email link from the first day. Single sign-on and directory sync come from the Customer's own identity system:

1. [`Tenant.requestSetup`](/business/nouns/tenant/request-setup) sends the Customer's IT admin a setup link.
2. They connect their sign-in, and [`SSOConnection.activate`](/business/nouns/sso-connection/activate) turns it on once a test sign-in passes.
3. A [Member Directory](/business/nouns/member-directory) pushes their people and groups in, so access follows employment.

A leaver removed from the Customer's directory loses access to the Tenant on the next sync. [Set up SSO for a customer](/products/app/set-up-sso-for-a-customer) walks through it.

## Agents as members
A buyer's [Agent](/business/nouns/agent) can accept an Offer and provision a Tenant itself, and a person claims the admin seat later. An agent member holds an Access Level and calls through the same Permissions as a person. Every call it makes leaves an Action with the agent as `by` and its person as `for`.

## Next
- [Tenant settings](/products/app/settings): what a Tenant's admin changes.
- [Customer access](/systems/customer-access): the [System](/business/nouns/system) behind every part of this chapter.