Permissions & Roles
Livy uses role-based access control. Each authenticated user has exactly one role per organization. Anonymous visitors are always treated as public.
Roles, Ranked Least → Most Privileged
| Role | Who they are | What they can do |
|---|---|---|
| Public | Anonymous visitors — no login required | Read published agendas and items, leave public comments |
| Guest | Registered users without staff status | Submit comments while signed in, edit only items they personally authored |
| Staff | Department members who draft agenda content | Create and update items, upload attachments, leave staff-only comments, approve items they're listed on |
| Admin | Operations administrators | Everything Staff can do, plus: announce and publish meetings, record votes, manage users (except other Admins), configure approval routines, manage most org settings |
| Super Admin | Highest privilege within an org — typically the clerk or org owner | Everything Admin can do, plus: manage other Admins, configure org-wide settings (branding, noticing laws, integrations) |
Reads cascade — a Super Admin sees everything Staff sees — but writes are granted per role. The matrix below is authoritative for any specific permission.
Recommended Role Assignments
A typical municipal mapping. Adjust to your jurisdiction.
| Role | Who typically gets it |
|---|---|
| Super Admin | Clerk's office and a small subset of IT — they manage other Admins and configure the org |
| Admin | Department Heads, Legal, and other power users — they announce meetings, publish agendas, record votes |
| Staff | Most people contributing to staff reports — analysts, planners, project managers |
| Guest | Consultants and occasional users — limited-scope contributors |
Two rules of thumb:
- Default to the lowest role that does the job. Promoting later is one click; over-permissioning quietly is harder to notice.
- Keep the Super Admin list short — typically the Clerk and one or two IT contacts.
How Permissions Are Enforced
Every change you make on the server passes through a permission check that compares your role against the list of roles allowed for that action.
Permission keys follow the pattern resource:verb[:scope]:
agenda-item:create— can create agenda itemsagenda-item:update:own— can update items they authoredagenda-item:update:any— can update anyone's itemsmeeting:publish— can publish a meeting's agendasettings:manage:org— can change org-wide settings (Super Admin only)
Every action is re-checked on the server, so a hidden button is never the real protection.
Info
Permissions are checked on the server for every action, not by hiding buttons in the screen. The matrix below is the one place to answer "who can do X?".
Full Permission Matrix
Pulled straight from Livy's live permission settings. A check means allowed; a dash means not.
| Permission | Public | Guest | Roster Member | Staff | Admin | Super Admin |
|---|---|---|---|---|---|---|
agenda-item : create | - | - | - | |||
agenda-item : read : published | - | |||||
agenda-item : read : draft | - | - | - | |||
agenda-item : update : own | - | - | - | |||
agenda-item : update : any | - | - | - | - | ||
agenda-item : delete | - | - | - | - | ||
agenda-item : approve | - | - | - | |||
agenda-item : approve : on-behalf | - | - | - | |||
agenda-item : create : closed session | - | - | - | - | ||
agenda-item : read : closed session | - | - | - | - | ||
approval-routine : configure | - | - | - | - | ||
approval-routine : apply | - | - | - | |||
watcher : manage : others | - | - | - | - | ||
entity : share | - | - | ||||
meeting : create | - | - | - | - | ||
meeting : update | - | - | - | - | ||
meeting : publish | - | - | - | - | ||
meeting : delete | - | - | - | - | ||
meeting : run | - | - | - | |||
meeting : minutes : write | - | - | - | |||
meeting : minutes : publish | - | - | - | |||
agenda : publish | - | - | - | - | ||
comment : create : public | - | |||||
comment : update : own | - | |||||
comment : delete : own | - | |||||
comment : create : staff | - | - | - | |||
comment : read : staff | - | - | - | |||
comment : reply : public | - | - | - | |||
comment : moderate : public | - | - | - | - | ||
comment : mention | - | - | - | |||
comment : generate : ai report | - | - | - | |||
vote : record | - | - | - | |||
vote : cast : self | - | - | ||||
hand : raise : self | - | - | ||||
attendance : record : self | - | - | ||||
attachment : upload | - | - | - | |||
attachment : delete | - | - | - | - | ||
user : read | - | - | - | |||
user : invite | - | - | - | |||
user : manage | - | - | - | - | ||
user : manage : admins | - | - | - | - | - | |
department : manage | - | - | - | - | ||
settings : manage | - | - | - | - | ||
settings : manage : org | - | - | - | - | - | |
settings : item-types : manage | - | - | - | - | ||
wiki : page : write | - | - | - | |||
wiki : collection : configure | - | - | - | - | ||
body : document : manage | - | - | - | - | ||
body : announcement : manage | - | - | - | - | ||
relationship : write | - | - | - | |||
chat : use | - | - | - | |||
chat : admin : configure | - | - | - | - | ||
settings : sso : manage | - | - | - | - | - | |
auth : mfa : manage : self | ||||||
roster-portal : access | - | - | ||||
user : mfa : clear | - | - | - | - | - | |
scim : configure | - | - | - | - | - | - |
Closed-Session Confidentiality
Items of a confidential type (like the built-in closed_session) have stricter rules layered on top of the matrix:
- A confidential item starts with its General Access set to Restricted — only Super Admin, Admin, and the people on the item (owner, approvers, anyone invited) can open the full content
- Everyone else on the staff side sees the item by title only — descriptions, recommended actions, fiscal impact, and metadata are removed before the data is sent to the browser
- An Admin can deliberately widen a specific confidential item via Manage access (in the item's actions menu) — lowering General Access to Staff and up opens that one item's full content to staff
- Only Super Admin and Admin can create or edit confidential items
- Attachments follow the same restriction as the item body
- Published agendas and PDFs include them as title-only entries (so noticing requirements are satisfied), regardless of the staff-side access level
Important
This redaction happens on the server, not just in the screen you see. Even a direct data request removes closed-session details for roles that aren't allowed to see them.
Common Surprises
- Staff can create items but can't publish agendas or manage meetings.
- Staff is the lowest role allowed to approve. Guests cannot be approvers.
- Guests edit only their own items and have no organizational write access.
- Org-wide settings (branding, noticing laws, integrations) require Super Admin specifically. Day-to-day org settings (PDF formatting, approval routines, public comment toggles) are also touchable by Admin.
- Public comments require a signed-in community account with a verified email (free self-signup). Anonymous submission is not supported.
- Approval routines: Admin and Super Admin configure templates; Staff can apply an existing routine but can't create new ones.
Related
- Approval Workflow — how approvers interact with items
- Audit Logging — every permission-gated action is recorded
- Comments — staff vs. public comment visibility