Customer access
Customer access governs who acts in each Customer’s Tenant: members, invitations, Roles, Permissions, sign-in connections, directory sync and keys.
Customer access decides who acts inside each Customer’s Tenant: members, invitations, Roles, Permissions, single sign-on, directory sync and API keys. A buyer’s Agent provisions a Tenant itself, and a Human admin claims it later.
Summary
| Part | This System |
|---|---|
| Group | Customers and identity |
| Status | Live |
| Shelf | Front: offered from a Startup’s first days |
You can ask:
- “Let a customer invite their team”
- “Turn on SSO for this customer”
- “Give their IT admin a setup link”
- “Remove this person’s access”
What you get
| Part | This System |
|---|---|
| Starts | On for every Startup at creation, with nothing to install. |
| Built from | Identity, Permissions, Tenancy, Audit log |
Nouns it owns
| Noun | Definition |
|---|---|
| Tenant | A Tenant is the partition of a Startup’s data that belongs to one Customer. |
| Permission | A Permission is what a Role may do: a Verb on a Noun within a scope, optionally bounded by a Limit. |
| SSO Connection | An SSO Connection links a Customer’s own identity system to its Tenant, so the Customer’s people sign in through it. |
| Member Directory | A Member Directory is a Customer’s own list of people and groups, pushed into its Tenant so access follows employment. |
Verbs
Events
| Direction | Event | How |
|---|---|---|
| Emits | Tenant.provisioned | By Tenant.provision |
| Emits | Human.invited | By Human.invite |
| Emits | Permission.created | By Permission.create |
| Emits | Permission.updated | By Permission.update |
| Emits | Tenant.invited | By Tenant.invite |
| Emits | Tenant.setupRequested | By Tenant.requestSetup |
| Emits | SSOConnection.activated | By SSOConnection.activate |
| Emits | MemberDirectory.provisioned | By MemberDirectory.provision |
| Emits | MemberDirectory.deprovisioned | By MemberDirectory.deprovision |
| Emits | SSOConnection.deactivated | By SSOConnection.deactivate |
| Emits | MemberDirectory.deactivated | By MemberDirectory.deactivate |
| Emits | SSOConnection.failed | Raised by the rail |
| Emits | MemberDirectory.failed | Raised by the rail |
States
The lifecycle of a SSO Connection:
| State | Meaning | Moves to |
|---|---|---|
draft (first) | Its configuration is entered, and no test sign-in has passed. | active by SSOConnection.activate |
active | Everyone in the Tenant signs in through it. | failing on SSOConnection.failed; inactive by SSOConnection.deactivate |
failing | Sign-ins through it fail, and the Customer’s admin has been told why. | active by SSOConnection.activate; inactive by SSOConnection.deactivate |
inactive | Turned off: nobody signs in through it, and its configuration is kept. | active by SSOConnection.activate |
Its other Nouns with a lifecycle: Member Directory.
Who operates it
| Part | This System |
|---|---|
| Accountable | Security Engineer |
| Team | Engineering Team |
| Seat | A role agent holds it until a Human is seated. |
| Autonomy | supervised |
| Also calls its Verbs | Integration Engineer, Onboarding Specialist, People Lead, Recruiter |
Approvals and limits
| Verb | Rule | Detail |
|---|---|---|
| Human.invite | Mandate trial for the Recruiter | Invites candidates to paid work trials and verifies their Credentials. |
Processes that use it
| Process | How it uses it |
|---|---|
| Security | A Workflow writes Permission |
| Onboarding | A step calls Tenant.provision |
| Staffing | A step calls Permission.create |
Rail underneath
None.
Views and dashboards
| View | Shows | Metrics |
|---|---|---|
| The Security Engineer’s view | The Metrics its accountable Role answers for. | Unused Permissions |
Access
What each Access level may call here.
| Access level | May call |
|---|---|
owner | Every Verb (27) |
admin | Every Verb (27) |
member | All but 12 of 27: MemberDirectory.create, MemberDirectory.update, MemberDirectory.deactivate, MemberDirectory.deprovision, MemberDirectory.provision, Permission.create, … |
viewer | Read only (8 of 27) |
Import and export
None.
Fees and pricing
None.
Availability and limits
| Part | This System |
|---|---|
| Status | Live |
Compliance notes
Every sign-in and Permission change lands in the audit log; who a Customer admits stays theirs.
Controls it carries:
- Action accountability
- Log completeness
- Authenticated Actions
- Task-bound access
- Permission decay
- Permission widening
- Namespace isolation
- Append-only records
- Revert by query
- Input validation
- Purpose limitation
- Disclosure record
Related Systems
Example
A Headless SaaS for invoice parsing sells b2a2b: a finance team’s Agent signs up, provisions a Tenant and starts calling the API. When the controller arrives, one link makes her the Tenant admin, and her company’s single sign-on takes over every seat.