App per Persona: derivation rules
The design rules that turn each Persona and its Access level into lists, forms, approval cards, a usage panel and an ask control for a Customer's people.
In the design, each Persona of an App gets its own screens, derived from the Access Level it holds in a Customer's Tenant. The rules below name what each Persona sees; no code serves them today.
What a Persona adds to the definition
The Admin derives one set of screens for the Startup's own team. An App per Persona derives one set for each kind of person at a Customer. It reads three more facts: the Personas, the Access level each holds, and the screen each opens on.
For leaseclock.com, a property management company has three kinds of people. The App file names them, beside the Property and Lease Nouns of The leaseclock.com sample.
---
kind: saas
mount: /app
nouns: [Property, Lease]
personas:
manager: { access: admin, opens: leases }
assistant: { access: member, opens: leases }
landlord: { access: viewer, opens: properties }
---admin, member and viewer are Access level presets. Each one grants read, write or every Verb on a set of Nouns, and the rules read nothing else.
Lists and forms inside the Access level
In the design, a Persona sees a screen only when its Access level grants the Verb behind it. A screen the Access level cannot reach has no route, no menu entry and no button pointing at it.
| Rule | When the definition has | Each Persona sees |
|---|---|---|
persona-screens | an Access level that grants get and list on a Noun | that Noun's list and record page; no screen for a Noun it cannot read |
persona-forms | an Access level that grants create or update on a Noun | the create or edit form; a record page with no Edit without it |
persona-actions | an Access level that grants a Verb beyond the standard five | its button, by omit-by-access; no button without the grant |
persona-verb-forms | a granted Verb declared with inputs, such as renew: { months: integer } | a form for those inputs, by action-form-from-inputs |
persona-home | opens on the Persona | that list as the first screen after sign-in |
tenant-scope | a Persona at a Customer | only the records in that Customer's Tenant, on every list and picker |
offer-lock | a Verb the Access level grants and the Customer's Offer does not | the button with a lock and the Offer that grants it |
For Lease on leaseclock.com, the three Personas see three different Apps over one definition.
| Persona | Access level | Lease list | Lease forms | Renew and Terminate |
|---|---|---|---|---|
| manager | admin | yes, first screen | create and edit | on each row and the record page |
| assistant | member | yes, first screen | create and edit | on each row and the record page |
| landlord | viewer | yes | none | none |
The manager and the assistant differ on the Nouns that decide access. Only the manager reaches the members screen to invite people.
Approval cards, a usage panel and an ask control
Three parts sit on every Persona's App, whatever its Nouns. Each reads records the platform already holds.
| Rule | When the definition has | Each Persona sees |
|---|---|---|
approval-cards | an Approval the Access level may answer | a card with the pending Action, the Limit it exceeds, and buttons for Approval.approve and Approval.refuse |
usage-panel | Entitlements with Limits on the Customer's Subscription | one bar per Entitlement: used, left, and what happens at the bound |
ask-control | any App | one control that sends Problem.suggest, recording the request with the asker attached |
On leaseclock.com, a starter Offer capped at 50 leases shows the manager a usage bar at 41 of 50. An assistant who asks for bulk import sends one Problem.suggest, and the Startup sees who asked.
What blocks these rules
Two gaps stand between the design and code that serves it.
- Who holds an Access level in a Tenant. The registry defines an Access Level as a preset a Worker holds. A property manager at a Customer is not a Worker of leaseclock.com, so no rule above has an Access level to read.
- Where the check runs. In the design, the Verb checks every Permission on every call, and a screen omits only what that check refuses. The Admin runs a Verb's rules in the browser, so
api-enforces-permissionswaits, and no omission counts as enforcement.
Tenants, seats and access in an App: depth covers how a Persona's seat and Access level meet the Offer.
Admin overrides
The knobs a Startup sets to change what the Admin derives, such as a Noun's icon, the field that names a record, a hidden field and extra screens.
Tenants, seats and access in an App: depth
How a Customer's Tenant, each person's seat and each Persona's Access level decide what an App renders and what the Offer charges, in the design.