Permissions Matrix
ZenPrint uses resource-action permissions: each role grants view / create / edit / delete per resource type. A few resources only use a subset of the actions: scripts and audit_log are view-only, and webhooks is view + edit.
System roles
Three roles ship with every tenant. They’re created automatically and can’t be edited or deleted.
Admin
Every permission, on every resource, across every client. The admin role isn’t scoped: it always sees the whole tenant. If you want admin-like access limited to specific clients, create a custom role with all permissions and add scopes (see Client scoping).
Technician
Create, view, and edit on operational resources. No delete, and no access to users, API keys, scripts, or webhooks. Built for the daily-driver case: technicians can capture drivers, manage queues, and approve endpoints, but can’t burn down a queue or rotate an API key.
Read-Only
View on operational resources, plus the audit log. Nothing else. Useful for stakeholders who want fleet visibility without the risk of click-to-mutate.
Resource × action matrix
| Resource | Admin | Technician | Read-Only |
|---|---|---|---|
clients | C R U D | C R U — | — R — — |
locations | C R U D | C R U — | — R — — |
devices (printers) | C R U D | C R U — | — R — — |
queues | C R U D | C R U — | — R — — |
drivers | C R U D | C R U — | — R — — |
endpoints | C R U D | C R U — | — R — — |
users | C R U D | — | — |
api_keys | C R U D | — | — |
scripts | view | — | — |
webhooks | C R U D | — | — |
audit_log | view | view | view |
C = create, R = view, U = edit, D = delete. A dash means no access.
scripts controls the Scripts tab (the bootstrap-script download); it’s view-only. webhooks controls the Alerting tab as a normal CRUD resource: view shows the channels and endpoints read-only, create adds a webhook endpoint, edit changes anything on the tab (the email and webhook event tables, supply thresholds, per-channel recovery toggles, SMTP relay settings, recipients, and the Test deliveries), delete removes an endpoint. These were one combined settings permission before; they’re split so you can grant webhook management without handing over the RMM bootstrap script, and vice versa. Users, API keys, and roles each have their own rows above, even though they all live on the same Settings page. (Editing the organization’s own name/email and the Organization tab, including the workspace timezone, is admin-tier and rides the users edit permission.)
Custom roles
Create custom roles under Settings → Roles → Create Role. You’ll see a checkbox for every cell in the matrix above, plus a client-scope picker (see below).
Custom roles get exactly the cells you check; there’s no all-access shortcut like the admin role has. To grant admin-but-scoped access, check every cell and add client scopes.
Assign custom roles to users under Settings → Users → Edit → Role. A user with no role assigned can log in but can’t do anything until you give them a role.
Client scoping
A custom role can be limited to one or more clients. A scoped user can only see and act on resources belonging to clients in their scope; anything else is refused. Leave the scope empty for tenant-wide access.
Scoping is enforced on the server, not just hidden in the UI, so it holds even if a scoped user tries to reach another customer’s resource directly.
How a permission check works
For each action a user takes, ZenPrint looks up their role, checks it grants that action on that resource type, and — if the role is scoped — checks the resource belongs to a client in scope. Fail either and the action is denied.
Role changes take effect on the user’s next login (or within a couple of hours).
Audit trail
Every permission-gated action is recorded in the audit log: who did what, to which resource, when, with any relevant context. View it under Settings → Audit Log. All three system roles can see it. Creating, editing, or deleting a role, and changing a role’s scope, are audited like any other action.