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 items
agenda-item:update:own — can update items they authored
agenda-item:update:any — can update anyone's items
meeting:publish — can publish a meeting's agenda
settings: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	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`	-	-	-
`meeting : create`	-	-	-
`meeting : update`	-	-	-
`meeting : publish`	-	-	-
`meeting : delete`	-	-	-
`meeting : run`	-	-
`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`	-	-
`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 type closed_session have stricter rules layered on top of the matrix:

Only Super Admin and Admin can create, view, or edit them
Public, Guest, and Staff see them by title only — descriptions, recommended actions, fiscal impact, and metadata are removed before the data is sent to the browser
Attachments are restricted to Super Admin and Admin
Published agendas and PDFs include them as title-only entries (so noticing requirements are satisfied)

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.

Approval Workflow — how approvers interact with items
Audit Logging — every permission-gated action is recorded
Comments — staff vs. public comment visibility

Due Dates Audit Logging