Roles and permissions
In short
Every app starts with Admin and User. Add roles on the Users page when you need more, give each role what it may do, and assign people to roles there or let the app’s admins do it. Nothing is allowed unless something allows it, and a deny always wins.
Most apps start with two kinds of people — someone who runs it and everyone else — and sooner or later need more: someone who can only read, someone who approves invoices, a contractor who must not see prices. Sapilon gives your app one way to say who may do what. It starts simple and grows without ever making you start over.
The one rule
Nothing is allowed unless something allows it. If anything says no, the answer is no.
An empty role can do nothing. An unticked box means “not allowed”. When two settings disagree — one role allows, another denies — the deny wins. That is all there is to remember.
Five levels, one editor
The editor opens at the simplest level that can show what you have set up, and More options steps up when you need it. Nothing is converted or migrated when you do — it is the same settings, shown in more detail.
| Level | You see | Use it when |
|---|---|---|
| 1 | Admin and User | Two kinds of people are enough. Admins can do everything; users get what you tick for them. |
| 2 | Roles | You need more kinds of people — Viewer, Editor, Finance. Start a role from a preset (Viewer, Editor, Admin or blank), and let a role include another (“Super user includes Editor”). |
| 3 | Permissions | Each role gets a checklist of the app’s areas and abilities — “Admin panel”, “Approve invoices”. Most apps stop here. |
| 4 | Resources | You need precision: a grid of every area against what can be done there — view, edit, delete, approve — and, for records, “only report 42 and 57”. |
| 5 | Allow and Deny | A cell can also be a red cross. A People tab holds exceptions for one person (“Sam can’t delete invoices”), and Check access answers “Can Sam approve invoice 42?” and shows which setting decided it. |
Ticking edit also ticks view, because you can’t edit what you can’t see. A deny on view also blocks edit, run and delete.
Where you edit what
| Users → Roles (you, building the app) | The app’s own Access screen (its admins, once live) | |
|---|---|---|
| Roles and what they can do | Yes — saved into the app and applied at your next publish | The roles you made are read-only there, marked “Set by the app’s builder” |
| New roles | Yes | Yes — the app’s admins can add their own and give them access |
Who is in which role is the People tab of Users, per server, and the app’s own Access screen — it takes effect within seconds either way.
The first admin
The first person to sign in to a new app becomes its Admin. Everyone after that joins the role you chose as “New people join”. An admin can’t be locked out: the last admin can’t be removed, and an admin can’t be denied anything.
Trying a role before you publish
On the Build Server’s test-user page, each test user shows their roles, and a new test user can be created straight into one (“New test user as Finance”). Open two tabs as different users to see what each of them can and can’t do.
Ask the agent
The agent adds the areas your app protects (the “resources” and “permissions” the editor offers) as it builds features. If a level shows “Your app hasn’t declared any areas yet”, ask the agent to add them — for example, “Make invoices something only Finance can approve.”