People and roles
Three roles, what each can do, how they apply to the builder as well as to the buttons, and why they belong to a workspace rather than to an account.
Three roles. Each person in the workspace has one — in this workspace. Somebody in more than one holds a role in each, and they do not have to match.
| Role | Can |
|---|---|
| Owner | Everything below, plus managing the team, renaming the workspace, setting its domain, deleting applications, clearing out an application's data, and downloading the source |
| Builder | Create applications, direct the builder, save versions, deploy, publish files, add and correct records |
| Viewer | Read applications, previews and what they have stored. Nothing that changes or ships anything |
Choosing one#
Viewer for somebody who needs to see what is being built — a stakeholder, a colleague in another department, a client if you have given them an account.
Builder for anybody doing the work. This is most people.
Owner for the small number of people who should be able to delete things, change the workspace domain, and take the source away.
The roles apply to the builder too#
This is the part worth understanding.
When you ask the builder to do something — deploy, add a user, connect a domain — it acts as you. Your role is resolved and enforced in exactly the same code the buttons go through.
So a viewer cannot deploy by asking nicely, and an owner-only action stays owner-only however it is phrased. There is no way round the roles through the conversation, which is the point.
Adding somebody#
An owner presses Add teammate on the Team page and gives an email address and a role.
If that address is new to the platform, set a password for them to start with and pass it on. If it already has an account — because they work in another workspace, perhaps yours and a client's — they simply join this one and keep the password they already had.
Roles can be changed afterwards from the dropdown beside each person, and somebody can be taken out with the button at the end of their row. Removing them signs them out of this workspace at once and touches nothing else they have: their account, and any other workspace they are in, carry on.
The last owner#
A workspace with no owner cannot be administered by anybody, and there is no way back from that. So the only owner cannot be stepped down, removed, or leave of their own accord. Make somebody else an owner first, and then any of the three is fine.
Sessions#
Signing in creates a session that can be revoked immediately. Removing somebody from the workspace, or suspending them, signs them out at once rather than waiting for something to expire.
What only an owner can do#
- Manage the team.
- Rename the workspace and set its domain.
- Delete an application.
- Empty or delete a table, or empty a whole environment, on the Data tab.
- Remove somebody from the user directory.
- Download source.
That last one is deliberate: taking an application away in full is a considered act with a technical colleague in mind, not something to do by accident.