FAQ & Workflows

An item is publicly visible only when all of these are true:

1. The meeting is announced
2. The agenda is published
3. The item has a published copy
4. The meeting is not cancelled
5. The meeting is not archived

Walk the checklist:

1. Meeting announced? Check the meeting's Public Visibility card. If the status isn't Announced, use the announce action. Without this, the public can't see the meeting at all — even if the agenda is "published" internally.
2. Agenda published? The same card shows whether an agenda has been published. If not, trigger the publish action. Announcing and publishing are separate actions; both must happen. If the announcement-deadline check fails, you'll get a warning.
3. Item published? Open the item detail page. The header shows whether a published copy exists. The first agenda publish publishes a copy of every item on it. If your item still shows as never-published after the agenda is published, it was added afterward — publish the item explicitly.
4. Meeting cancelled? Cancellation hides everything. If the visibility card shows the meeting as cancelled, use the uncancel action. The announced and published states are preserved.
5. Meeting archived? Archived meetings disappear from every list. Check the archive list and unarchive.

Livy checks the same three things in one place — is the meeting announced, is the agenda published, and does the item have a published copy — so the staff view and the public view never disagree about what's visible.

Less-obvious gotchas:

• Closed-session items appear publicly by title only — descriptions, recommended actions, and attachments are withheld. See closed-session items.
• Deferred items carry their previously published copy until you republish on the new meeting.
• Approval state has no effect on visibility — approval is advisory.

Once a meeting is announced, the public knows it's happening — the date, time, and location are on the public portal, and announcing a second time isn't a meaningful action. The header collapses to the next two actionable buttons: Publish agenda (or Publish update (N) if you've made edits) and Publish record (which appears immediately, disabled until the meeting's scheduled start time passes).

To take a meeting back out of public view, use Cancel from the actions menu — that's what hides an announced meeting. Re-announcing isn't a flow.

Publishing the agenda also announces the meeting if it isn't already (both happen in one step), so a clerk who skips straight to Publish agenda will see Announce vanish at the same moment.

The button appears in the header as soon as the meeting is announced or its agenda is published — but stays disabled with "Available after the meeting starts" until the scheduled start time passes. Once the meeting is underway, the button becomes the highlighted action so a clerk can publish attendance, outcomes, and minutes during or after the meeting.

The button also stays disabled on cancelled or archived meetings (the actions menu carries Uncancel / Unarchive). The org-wide setting that turns public meeting records on or off doesn't disable the button — clerks can still press it, and an inline note below the record card explains that public visibility stays off until an admin turns it on.

Same underlying action; different copy. The first publish saves a copy of the live record (attendance, outcomes, annotations, minutes, votes) and makes it public. After that, any edit to one of those makes the Publish record button switch to Republish record — the public copy is now out of date and differs from what staff sees.

Three signals all light up together when the public record falls behind:

• The header button switches to Republish record (the highlighted action).
• The Record-tab section globe icons turn yellow (out of date).
• An "Unpublished record changes" warning appears in the warnings strip.

Republishing refreshes the public copy and clears all three signals. If you want to take the record back out of public view, use Withdraw from Public in the Actions ▾ menu — that pulls the announcement, agenda, and record all back to a private draft in one step.

Use Withdraw from Public in the Actions ▾ menu on the meeting detail page. It's the single reverse-action for the meeting lifecycle — one click clears the announcement, the agenda publish, and the record publish all at once. The meeting returns to a staff-only draft. Items, attendance, outcomes, and minutes are all preserved; only their public surface is withdrawn. You re-announce and re-publish piece by piece from there.

When to use it

• You announced the wrong meeting and need to pull it back before re-announcing.
• You published an agenda or record with content that shouldn't have been public yet.
• You need a clean slate to rework the meeting privately.

How it differs from Cancel and Archive

A cancelled or archived meeting can't be withdrawn directly — un-cancel or unarchive first, then withdraw. The Withdraw item is hidden from the Actions menu in those states to make this clear.

Yes. Once an agenda is published, the packet PDF refreshes automatically whenever something it shows changes:

• An item on the agenda is republished (its title, description, recommended action, or duration change).
• A public attachment is added, replaced, edited, removed, or toggled public/private.
• The meeting itself is edited in a way the PDF shows (title, body, date, start time, location, or header text).

The refresh runs in the background after your edit saves and overwrites the same PDF at the same URL — viewers who download right after a change may briefly get the previous version before the new one finishes (usually within a couple seconds).

What doesn't auto-update. Adding or removing items from the meeting, reordering sections, or editing section descriptions still requires an explicit republish — those structural changes create a new agenda version (v+1) with a fresh PDF.

Click any item's number in the agenda builder to edit it inline. The input pre-fills with just the {n} token (the pattern prefix — "Item ", "Resolution ", etc. — stays out of the way). Type a new value, press Enter.

Three things you can do:

Overrides don't cascade. Changing Item 2 to "AA" leaves Item 3 as "Item 3" — the type counter still advances past the renamed slot. Hiding a row works the same way. This is intentional: overrides are surgical edits, not bulk renumberings. If you want to renumber the whole agenda, reorder the items in the builder.

Resetting everything at once. The agenda's overflow menu carries Reset all custom numbers (N) when at least one override exists. One click clears every override on the meeting. There's no "reset just this section" affordance — it was deemed too buried to be useful; the per-row ↺ icon handles the targeted case.

An override is an unpublished edit. The row's Edited chip lights, the republish signal fires, and the publish-dialog changelog suggestion lists "(number)" as a changed field. Republishing saves the override into the published copy, and the public agenda + PDF show the new number. Until republish, the public sees the previously published number.

Permission: meeting:update (Admin or Super Admin). Staff and below can view but not change overrides.

For the full reference, see Numbering → Manual per-item overrides.

Add approvers to an item; each approves. When all have approved (and no one has an active rejection), the item is Approved. Rejection is advisory — it flags the concern but doesn't permanently block the item. For the underlying model, see Approval Workflow.

Two ways to assign approvers:

• Basic — open the approver-management UI on the item, add approvers one at a time. No order; any approver can approve at any time.
• Advanced (routines) — a saved, reusable approver list. Build the list on one item, save it as a routine, and apply that routine on future items. Routines live inside the same approver-management dialog (no separate settings page). Saving a routine requires Admin or Super Admin; loading and applying is Staff and above.

Rejection is advisory. Rejecting marks that approver as Rejected. It does not delete the item, prevent edits, or revoke other approvers' actions. If the author addresses the concern, the rejecting approver can Approve to clear the rejection, or Retract to clear both their rejection and approval.

Retracting your own approval. Retract on your row to undo your approval without rejecting. The item drops back to Pending.

Removing an approver. Admins can remove an approver at any time. State recomputes from the remaining rows.

Where approvers see pending items. A notification (in-app + email per their preferences) when added; the dashboard's Pending Review card shows items awaiting review.

Common gotchas:

• Approval doesn't block publishing by default. Publishing checks announcement compliance and quotas, not approval state.
• Routines are one-time copies. Loading and applying copies the routine's current state onto the item; updating the routine later doesn't change items you already applied it to.

Open Admin → Team, send an invite with the new member's email, pick a role, optionally assign a department. They get a verification email and complete onboarding from there.

Steps:

1. Open the team page — under Admin → Team. You need user:invite to invite — Staff, Admin, and Super Admin all have it. To invite or modify another Admin, you need to be Super Admin (user:manage:admins).
2. Send the invite — enter name and email. Livy emails them a verification link.
3. Pick a role:

Default to the lowest role that does the job — promoting later is one click. See Permissions & Roles for the full guidance and matrix.

4. (Optional) Assign a department — helps with approval routing and reporting. Change later from the team page.
5. The invitee completes setup — verifies email, sets a password, lands on the dashboard.

Common questions:

• Change someone's role: edit the row in the team page. Takes effect immediately and is audited. Changing to or from Admin requires Super Admin.
• Deactivate a user: hides them from active lists, prevents login, preserves all history. Reversible. Don't delete users — deactivate.
• Bulk-invite: not supported; invites are one at a time.

The invitee's onboarding mirrors self-signup, except org membership is pre-attached.

Walk this checklist top to bottom — each layer can shut off notifications:

1. You're the actor. The user who triggered the event never receives their own notification.
2. You don't match the audience rule for that event.
3. Your user preference has the channel disabled.
4. The org default has the channel disabled.
5. You haven't verified your email (email channel only).
6. It's still being sent. Notifications go out in the background — there's a brief delay.

Resolution order. When an event happens:

1. Audience rule — every event in the catalog declares who's eligible. If you don't match, you don't get one.
2. Per-user preference — does the user have in-app and/or email enabled for this event? User preferences override org defaults.
3. Org default — fallback when the user hasn't set a preference.
4. Channel gates — channel-specific prerequisites (e.g., a usable email address for email).

Any rung saying no kills the notification.

Diagnose by symptom:

• Not getting any notifications: you may be the one triggering every event you'd otherwise be notified about (you're never notified of your own actions); your email may be unverified; both channels may be off across your notification preferences (under Settings → User).
• Email's missing, in-app works: verify your email; the org's email integration may not be configured. In dev/staging, all email is redirected to a single test inbox.
• In-app's missing, email works: open the in-app notification center. If rows exist but the unread indicator is off, refresh.
• Only one event type is missing: almost always a preference issue. Find the event in your notification preferences and confirm the channel is on. If the org default has it off, your preference must explicitly turn it on.
• There's a delay: expected. Notifications go out in the background; most arrive within seconds. Failed deliveries are retried automatically.

Enable in settings. Members of the public sign up for a free community account, verify their email, and submit comments through the portal. The commenter's name is taken from their account; the comment is visible immediately, and PII is stripped before non-staff readers see the thread.

Who can comment: anyone with a verified community account. The verified-email requirement is the basic bot protection — there's no separate bot-trap or captcha on the comment form itself (captcha protects the signup and password-reset flows instead).

End-to-end flow:

1. Admin enables public comments under Settings → Meeting. Per-item flags still win — staff can disable comments on a specific item.
2. The visitor signs up for a community account (email + password), verifies their email, then signs in.
3. They submit a comment (1–5,000 chars). Name comes from their account; no separate form fields. The comment is saved under their account and visible immediately.
4. Personal details removed before display — email, IP address, and browser info are removed for non-staff readers. The public sees the name and comment text; staff see the full record.

Staff-logged public comments. Staff can record public comments that arrived another way — email, letter, phone, in person — as the same kind of public comment. Each one notes how it arrived (portal, email, letter, phone, in person, or other) and which staffer logged it, so its origin stays auditable.

Three moderator actions on the comment's actions menu: Hide From Public, Delete Permanently (admins only), and Restore. All three are gated by comment:moderate:public (admin + super_admin). Authors can delete their own comments without moderator permission, but "Delete Permanently" is admins only.

Hide vs Delete — when to pick which:

• Hide From Public is the default. The comment is hidden, not erased: it stays stored with its text intact, but the public no longer sees it. Use this for accidental duplicate submissions, off-topic remarks, or anything you might want to bring back.
• Delete Permanently is for malware links, illegal content, or anything that shouldn't remain on your systems. It permanently removes the comment. Cannot be undone.
• Restore is the reverse of Hide — brings a hidden comment back to its original live state. Only hidden comments can be restored; permanently deleted ones are gone.

Reason field — when's it asked?

One toggle, two modes. Off by default, all three moderator actions skip the reason field entirely — confirm-and-go UX. Flip the toggle on at Settings → Meeting → Public Comments → Moderation and every moderator action (hide / delete permanently / restore) requires a reason.

Orgs that flip the toggle on accept the cost of capturing restoration intent in writing (a restore-reason can read as legally sensitive in discovery) in exchange for a complete moderation trail. Orgs that leave it off see no reason fields anywhere on the moderator path.

What the public sees:

A hidden comment disappears entirely from the portal — no placeholder. Exception: if a staff reply hangs off the hidden comment, a [removed by moderator] placeholder stays so the reply has context. Staff always see these placeholders in the thread, so they have at-a-glance context while reviewing. The agenda PDF rebuilds itself after moderation so the printed packet stays in sync.

Nobody is notified. The original commenter is never told that their comment was hidden, deleted, or restored. Other admins aren't notified either. Moderation activity shows up on the per-item Changelog tab when staff look.

See Comments — Moderation for the full table of states, the audit-trail wording, and PDF-rebuild behavior.

Set the item type to Closed Session. The title stays on the public agenda — required by most open-meetings laws so the public knows the item exists. Description, recommended action, fiscal impact, and attachments are withheld from the public. Only Admin and Super Admin can create or read the full content.

Why the title stays public. Open-meetings laws generally require even closed-session topics to be announced so the public knows what subject is being discussed in private. Hiding the title would defeat that.

The system splits the item:

• Public view — title and the closed-session marker. Everything else is replaced with a placeholder.
• Staff view — full content, Admin and Super Admin only. Even Staff users see the redacted view.

The redaction is enforced on the server, not just in the screen you see.

Steps:

1. Mark closed-session. In the item editor, choose Closed Session from the type selector. The closed-session type itself is the marker — there's no separate flag. Only Admin and Super Admin can create or edit closed-session items (agenda-item:create:closed_session).
2. Add the confidential content. Description, recommended action, attachments — write as normal. Visible to Admin and Super Admin only.
3. Publish as normal. Closed-session items go through the same publish flow. The full content is stored either way; what's withheld depends on who's reading.

What the public sees: the title as written, the type ("Closed Session"), and a placeholder where the description, recommended action, fiscal impact, and attachments would normally be. PDFs apply the same redaction.

Comments: most orgs disable public comments on closed-session items in the meeting-level public-comment settings.

Removing the closed-session type: change the type and republish to update the public copy.

Settings is split into tabs (Org, Agenda Item, Meeting, Bodies, User). For branding and PDFs you'll mostly be in:

• Org tab — name/address/timezone, default language, noticing law, branding (logo + primary color), public-directory toggle
• Meeting tab — vote/record options, PDF export, public comments

Org and Meeting settings require Super Admin or Admin. Org-wide bits like noticing law and integrations are Super Admin only.

Org-level identity & branding:

• Identity fields are mostly set during onboarding. Revisit when org name, address, or timezone changes; you want a different default language; or the noticing law changes.
• Logo — paste an S3 storage key for your logo (PNG or JPG). Upload to your S3 bucket via your normal flow, then enter the key. Appears on agenda PDF cover pages and the public portal.
• Primary color — a single hex picker. Used as an accent in the portal and PDF cover page header.

PDF export options currently exposed:

• Cover Page — header text shown above the meeting body name on the cover; an option to format the meeting preamble as markdown.
• Page Layout — page size: Letter or A4.
• Content Options — toggles for including attachments, including a table of contents, and showing recommended actions.
• Overlays — toggles for an item-label stamp on item/attachment pages and a packet page-number stamp.

Common questions:

• Different branding per body? No — branding is org-level. Each body can have its own photo and description in the public directory (new body).
• Undo a settings change? Audit logs capture the previous value; reference the audit entry and re-enter it. There's no rollback button.
• Why doesn't my logo appear on existing PDFs? PDFs are stored at publish time. Regenerate on the meeting to pick up the new logo.

A body is a group that meets — city council, planning commission, library board. From the bodies settings, create one, drill into its detail page to add members, optionally upload a photo, define templates if you want them seeded into every meeting, and toggle public-directory visibility.

Body management requires Admin or Super Admin (department:manage). Staff can read bodies but can't create or edit them.

Steps:

1. Create the body in the bodies settings (Settings → Bodies):
   • Name — public-facing (e.g., "City Council")
   • Slug — auto-derived; unique within the org. Collisions get a numeric suffix.
   • Parent body (optional) — for nested hierarchies. Max nesting depth is currently 2.
2. Open the body's detail page — separate from the settings list. Use this page to manage members, upload a photo, edit templates, and toggle per-body publicity.
3. Upload a photo (optional). Allowed: PNG, JPEG, WebP, up to the image size limit.
4. Add members. Body members are the seats — elected officials, appointed members — separate from user accounts. Each member row stores name (required), title (optional), and an active flag.
5. (Optional) Define templates — preamble templates (opening items like "Pledge of Allegiance") and section templates (agenda sections like "Consent Calendar"). Templates project into the same row shape the agenda builder uses, so what the body builder shows is exactly what new meetings start with. Edits only affect new meetings.
6. Toggle public-directory visibility. Each body has its own public/private switch on Settings → Bodies. When public, the body appears in the public directory, and its public page shows the photo, description, and active member roster. The public Bodies tab is hidden entirely if no body is marked public.

Lifecycle. A body is Active, Inactive, or Archived:

• Active — appears in all staff and (if enabled) public lists.
• Inactive — hidden from the public, still visible to staff.
• Archived — hidden from staff lists too. Past meetings and items remain.

Common questions:

• Move meetings between bodies? No — meetings are owned by the body that created them.
• Deactivate a member with vote history? Toggle the member's Active flag off rather than deleting the row. Past attendance and vote records stay attributed.
• Per-body permissions? No. Permissions are role-based at the org level.