Skip to content

Roles

Viewer, operator and admin — a table of what each may do, row by row, and three rules about your own account.

Three roles, nested: each can do everything the one below it can. The application describes them in three sentences, and this page writes them out.

The three roles

RoleHow the application describes it
viewerReads everything. Changes nothing.
operatorCreates, edits and runs jobs. Not agents, not accounts.
adminEverything, including agents, accounts and deleting jobs.

A role is a property of an account within a workspace. It is read on every request, not at sign-in, so lowering a role, blocking an account or deleting one takes effect from the next click — not from the next sign-in.

Who may do what

The table is a transcription of the rules the API decides by; every row is one decision. Why deleting a job is an admin's when editing it is an operator's: it deletes the whole run history.

Actionvieweroperatoradmin
the dashboard, the job list, a job's page, run history and output✓✓✓
the agent list, tags, statistics, upcoming runs✓✓✓
your own name, your own password, signing out✓✓✓
the overview of plans✓✓✓
create and edit a job✓✓
run a job now✓✓
remove a tag from a job✓✓
delete a job — and its run history with it✓
enrol, disable, reset and delete an agent✓
invite an account, change its name and role, block it, send a password reset, delete it✓
the audit log✓
exporting data✓
the workspace's timezone✓
the plan and billing✓

Actions that write also need an active workspace: in a suspended one, reading works and every change gets a 402.

Your own account

Three things Runjet refuses whatever your role, answering 409:

  • changing your own role — in either direction; an admin who demoted themselves by mistake could never come back,
  • blocking yourself,
  • deleting your own account.

Your own name and password, by contrast, are yours to change whatever your role, a viewer's included (your profile).

The last admin

A workspace must have at least one admin. Lowering the last one's role, blocking them or deleting them is refused with the sentence this is the only administrator — promote someone else first.

Hidden, not greyed out

A control your role may not use is simply not on the screen — not greyed out, not there. A screen full of dead buttons reads as a broken application. Where a control is also a display of state (the Enabled switch), the state stays and only the means of changing it goes. Your role is stated by the account menu in the header; it is there to answer the question "why can I not see that button". Colour marks the admin alone, because only an admin carries a consequence; the word is always beside it.

Hiding is a courtesy, not a protection: the API refuses the same request to anyone who builds the button themselves, answering 403 and naming the role that would have been enough (error responses).